From RedHa@aol.com Fri Feb 02 09:33:11 1996 

Received: from emout05.mail.aol.com (emout05.mail.aol.com [198.81.10.37]) by 
sysi.tapr.org (8.7.3/8.7.2) with SMTP id JAAQ4778 for <hfsig@tapr.org>; Fri, 2 Feb 
1996 09:33:08 -0600 (CST) 

From: RedHa@aol.com 

Received: by emout05.mail.aol.com (8.6.12/8.6.12) id KAA12933 for hfsig@tapr.org; 
Fri, 2 Feb 1996 10:32:36 -0500 

Date: Fri, 2 Feb 1996 10:32:36 -0500 

Message-ID: <960202103234_134001137@emout05.mail.aol.com> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:847] HFSIG digest 228 


Hi, Rick; 


Tnx for both recent forwardings and the concern for our well being. The 
articles provide me with material for our local network association (WANA) 
meetings. 


We were a bit more isolated than usual for about a week, as the phone line to 
the mobile home failed. I replaced it Wed and spent a lot of time reading 
the accumulated mail. 


What are your thoughts on coordinating node operation: frequency, ERP, 
directivity, etc.? 


I'm working on a plan to put wx info on the local BBS, possibly moving to a 
separate service located at the new LaCrosse NWS location when the ham 
installation there nears completion. My initial thought is to put the local 
Zone service from MNDOT on the BBS, with revision once or twice per day. If 
you haven't explored it, connect on 726 1140, user name CUHOME, and password 
MNDOT1. HELPOUT will get you the menu, HELPOUT (command) will get directions 
on using menu items, and INFO (command) will explain what each menu item 
provides. METRO will get you the local forecast, revised 3 or 4 times daily. 
Some commands are not explained well or at all. One such is ZONE. Try ZONE 
(2 letter state identifier). The zone info can be focused with ZONE MN/Z=95, 
or other state and zone identifier. It's provided by MNDOT, primarily 
advertised to pilots, but includes a lot of general road and wx info. 


Temp here was -30 F a while ago; up to -28 now! I'd try to make ice cream, 
but it would probably be grainy and I'd never get the dasher out. 


Snowshoes have become essential. Some of the frequently used tracks have 
become hard enough to negotiate in boots. I haven't had time to try the 
skiis. Now that the snow has firmed, they would probably be OK, but I don't 
think they were appropriate in 20 inches of fresh powder. Even the snowshoes 
sank about a foot at first. 


I'm working on two proposals at once, with deadlines today and Monday for 
first draft. Outside chores, like keeping cars running and the road open so 
the XYL can escape, interfere a lot. Sometimes I consider rejecting any 
assignment requiring output in less than 30 days, so that I can avoid some of 
the conflicts. 


I recommend a book, "Flyfishing Through the Midlife Crises", Howell Raines. 
He models his maturing philosophy of life with the anology of transitioning 
from the "Redneck way of fishing", to the dryfly purist who kills no fish. 


Well, I better get back to work. Hope school and all are going well for you 
and Barb and bid you keep warm! 


73 de Red 


From chbrain@dircon.co.uk Fri Feb 02 15:33:03 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
sysi.tapr.org (8.7.3/8.7.2) with SMTP id PAA18835 for <hfsig@tapr.org>; Fri, 2 Feb 
1996 15:32:58 -0600 (CST) 
Received: by felix.dircon.co.uk id AA18953 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Fri, 2 Feb 1996 21:32:29 GMT 
Message-Id: <199602022132.AA18953@felix.dircon.co.uk> 
Received: from gw2-138.pool.dircon.co.uk(194.112.35.138) by amnesiac via smap 
(V1.3) 
id sma018944; Fri Feb 2 21:32:20 1996 
X-Sender: chbrain@popmail.dircon.co.uk (Unverified) 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Fri, 02 Feb 1996 21:05:09 +0000 
To: hfsig@tapr.org 
From: chbrain@dircon.co.uk (Charles Brain) 
Subject: 8ary FSK 


In case anyone is interested, I have included a brief T.D of my modem. It 
is based very heavily on Adrian Nash's Piccolo modem. It's my first DSP 
project so it probably not the best implementation! !!! 


This is a brief description of how the 8ary FSK modem has been implemented 
on a TMS320C50 EVM (not DSK). 


1) The input signal is sampled at 8k samples per second. 

2) The signal is mixed with a sine and cos wave at 1625Hz. The 1625hz is 
generated with a lookup table, the transmit tones also use this lookup table. 
This moves the 8 tones symetrically around © Hz. As the signals are now 
complex their frequency sign is not lost. 

3) The I and Q channel that have been generated are now low pass filtered using 
a 32 tap FIR filter with a cutoff freqeuncy of 1khz. This filter also 
decimates the signal by four and places it's output into a 16 entry 
circular buffer. The effective sample rate is now 2Ks/s. 

4) The 16 samples from the I channel are placed in the 16 real input locations 
of a 16 point FFT. The 16 samples from the Q channel are placed in the 16 
complex input locations of the 16 point complex FFT. 

5) The FFT is run at each fourth input sample (2Khz). The input buffer to the 
FFT is in fact 1 bit period (8ms) in length, a happy coincidance. 

6) After each FFT the magnitude squared of each of the wanted frequency bins 


is calculated(square roots are expensive to calculate). Not all bins are 
used. 

When a bit completely fills the input window, the bin magnitude is ata 
maximum. 

7) The bin with the maximum output is divided by the sum of the magnitudes of 
all the other wanted bins. This waveform contains a component at the symbol 
rate. The result is filtered with a BPF centered at 125Hz (symbol rate). 
This signal is used to lock an NCO to the symbol rate. This locking code 
may need more work as I have not yet tested it on poor channels. 

8) When a symbol epoch arrives the bin with the largest magnitude is found and 
its symbol value is written to the host port. 

9) Data carrier detect is generated from the bit sync ‘'circuit', when bit sync 
is achieved DCD is signalled to the host P.C. This provides a fast DCD which 
is essential for rapid scanning. 


Notes. 

Although the main part of the code operates at 8khz the FFT, magnitude 
calculation, 

bit sync and symbol epoch calculation occur at 2khz, i.e they are scheduled. 
On the first 8k interrupt the FFT runs, next interrupt the magnitude 
calculation 

runs etc. 

The FFT algorithm is taken from the TI manual and uses a rectangular window. 
The filters were designed using PC-DSP and parts of the modem were simulated 
using 

PC-SIM. 

At present the whole modem operates within the interrupt. Future plans are 
to add 

some form of whitening filter. There are plenty of spare cycles left! 

It has been tested against the NTIA test waveforms (clean tones) and manages to 
achieve word sync and hold it. I haven't tried the degraded tones yet. 
Voting and Golay error correction are done within the P.C. 


The unused frequency bins could be used for frequency/doppler correction. I am 
not sure what frequency tolerance this modem requires. 


Charles G4GUO 


From karn@qualcomm.com Fri Feb 02 23:22:48 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.7.3/8.7.2) with ESMTP id XAAQ7806 for <hfsig@tapr.org>; Fri, 2 
Feb 1996 23:22:46 -0600 (CST) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.3/8.7.2/1.4) id 
VAA10891; Fri, 2 Feb 1996 21:22:10 -0800 (PST) 

Date: Fri, 2 Feb 1996 21:22:10 -0800 (PST) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199602030522.VAA10891@servo.qualcomm. com> 

To: chbrain@dircon.co.uk (Charles Brain) 

CC: hfsig@tapr.org 

In-reply-to: <199602022132.AA18953@felix.dircon.co.uk> (chbrain@dircon.co.uk) 
Subject: Re: [HFSIG:849] 8ary FSK 


Charles, 


Your system sounds most interesting. It's pretty much along the lines 
of the system I've been contemplating; it differs mainly in the 
numbers. Do you have any performance figures? I'm really curious. 


I have been thinking of much larger values of m, like 128 or 256, to 
improve Eb/NO performance. Coding over a noncoherent channel behaves 
very differently than on a coherent channel (e.g., BPSK). You gain by 
adding a little coding to both. But while the coherent channel 
asymptotically decreases in Eb/NO requirements as you decrease the 
code rate, the noncoherent channel ‘bottoms out' in its Eb/NO 
requirements at a certain critical code rate and then increases again 
as the code rate is further lowered. This is due to the inherent 
nonlinearities in noncoherent demodulation; as you decrease the code 
rate below the optimum you force the demodulator to work below its 
threshold. 


The minimum Eb/NO obtained at the optimum code rate is a strong 
function of m, the number of "tones", with larger m always giving 
better performance (assuming the symbol time doesn't become so long as 
to exceed the coherence time of the channel.) 


Nevertheless, uncoded noncoherent m=8 is already better on the Eb/NO 
score than uncoded xcoherent*x BPSK, which is not too shabby. I'm told 
that 8-ary FSK is common in military HF modems. 


I differ somewhat in my approach to synchronization. I need some sort 
of synchronization vector, which I plan to interleave with the data. 
Otherwise a fade at the front of the packet could clobber the sync, 
leaving the rest of the packet strong but unusable. 


My idea here is to slide a series of FFTs spaced at the separation of 
the individual sync symbols across the incoming audio in a buffer. 

The step would be perhaps 1/4 symbol, narrow enough to have a good 
chance of spotting the energy in a weak packet but not so narrow as to 
make the CPU requirements prohibitive. 


After FFTing and taking bin energy values, I sum all the energies in 
the bins corresponding to where the sync symbols should be, and from 
that I subtract the energies in all the other bins. If the result is 
larger than a threshold, I declare initial lock and begin a finer 
search in time to maximize this value. Now I know exactly where the 
packet begins and ends and also where the individual symbols begin and 
end. I then run my FFTs to recover the data symbols, producing in each 
case a set of soft decision values for the Viterbi or Fano decoder 
that follows. This I do for each bit within a symbol by summing all 
the FFT energy bins for which the bit in question is a "1" and 
subtracting all those for which the bit is a "0". This gives better 
soft metrics than just taking the energy bin with the largest 
magnitude and spitting out the hard-decoded log2(m) data bits that 
correspond to it. 


For large m, I could probably improve CPU performance considerably 


during sync search by just correlating with the appropriate sinusoids 
in the appropriate places and subtracting off total received energy 
from the sum of the correlator outputs. 


With modern clocks I shouldn't have to run any kind of tracking loop 
to recover symbol timing once I've acquired synchronization. In the 
event of a small symbol rate mismatch between sender and receiver, the 
interleaving of the sync vector with the data should help find the 
best compromise timing. Of course, the size of the data block will 
have to be limited to keep frequency errors from accumulating 
indefinitely. 


Oh, and I'll probably use a Hamming window on each symbol at both the 
transmitter and receiver to control spectral shaping and to mitigate 
intersymbol interference effects. 


Phil 


From chbrain@dircon.co.uk Sun Feb 04 03:13:39 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
sysi.tapr.org (8.7.3/8.7.2) with SMTP id DAA20941 for <hfsig@tapr.org>; Sun, 4 Feb 
1996 03:13:37 -0600 (CST) 
Received: by felix.dircon.co.uk id AA26783 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Sun, 4 Feb 1996 09:13:34 GMT 
Message-Id: <199602040913.AA26783@felix.dircon.co.uk> 
Received: from gw2-141.pool.dircon.co.uk(194.112.35.141) by amnesiac via smap 
(V1.3) 
id sma026773; Sun Feb 4 09:13:13 1996 
X-Sender: chbrain@popmail.dircon.co.uk (Unverified) 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Sun, 04 Feb 1996 08:45:45 +0000 
To: hfsig@tapr.org 
From: chbrain@dircon.co.uk (Charles Brain) 
Subject: Re: [HFSIG:850] Re: 8ary FSK 


>Charles, 

> 

>Your system sounds most interesting. It's pretty much along the lines 
>of the system I've been contemplating; it differs mainly in the 
>numbers. Do you have any performance figures? I'm really curious. 

> 

Hello Phil, 

I am afraid that at present I have no accurate way of measuring performance. 
This is one of the reasons I need to do further work on the sync. The setup I am 
using is a C50 EVM for the modem and a C50 DSK for a test generator. I have 
plans 
to use the DSK as a crude channel simulator, take the audio output of the 
EVM and 
set its S/N in the DSK add a random time offset (otherwise the modem doesn't 
have to 
search for sync) and send it back for decoding. 


I am also trying to improve my simulation capabilities, this weekend I have 
been porting 

an H.F Channel simulator written in C by Eric Johnson of NMSU to a form where 
I can call it from the macro language within PC-DSP, this allows me to take 

a signal 

add multipath/fading and doppler spread and pass it on to a simulated modem. 


When I get this going I will be able to investigate the effects of different 
window functions 
on multipath. 


Synchronization has proven to be the part that has given me the most trouble! 


Do you plan to send a single interleaved block of data in each frame or a 
number of 

blocks with selective repeats at the receiving end like some military modems 
do? Aka FS1052 

Appendix B ? 

Also how are you going to synchronize to the data, will it be a bi-product 
of the decoder 

or are you going to use a synch vector such as a Barker sequence? 


I assume you are not using phase information (from your description), and 
won't be using 

Ungerbock codes. There was an interesting article, I think it was repeated 
in Nordic 95 about 

the use of Ungerbock codes and parallel tone modems by Steve Cook. The paper 
originally 

appeared in the IEE York conferance on H.F in 1994. 


By the way I downloaded your Digital Audio Clips from your WWW page so I 
know what the real 
KA9Q sounds like ! 


I look forward to hearing you future explots and maybe I'll get to port your 
modem to my DSP 
platform one day! 


Regards Charles G4GUO. 


From forrerj@ucs.orst.edu Sun Feb 04 18:07:40 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org 
(8.7.3/8.7.2) with SMTP id SAA21773 for <HFSIG@TAPR.ORG>; Sun, 4 Feb 1996 18:07:32 
-Q600 (CST) 
Received: from p07.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/24Sep94-1201PM) 
id AAQ3512; Sun, 4 Feb 1996 16:07:11 -0800 
Message-Id: <9602050007 .AAQ3512@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 


Date: Sun, 04 Feb 1996 16:10:00 -0800 

To: HFSIG@tapr.org 

From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: EXPERIMENTAL HF MODEM BEACON PROJECT 


Hi all, 


I now have my hardware set up and ready to run different modem beacons on 
HF. The beacon runs in "attended" mode and by pre-arrangement. I can work on 
28, 21, 14, 7 and 3.5 MHz. 


The 15-tone modem has NOS capabilities, so a connection is possible. The 
SLOWBPSK modem is a beacon only, however, manual operation allows 
keyboard-to-keyboard QSO's. I will be happy to 

activate the sytem/beacon if anyone is interested in running some tests. 


-- Johan, KC7WW 


From FORRERJ@frl.orst.edu Wed Feb 07 11:48:04 1996 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
tapr.org (8.7.3/8.7.2) with SMTP id LAA13908 for <hfsig@tapr.org>; Wed, 7 Feb 1996 
11:48:01 -0600 (CST) 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id JAA25982 for <hfsig@tapr.org>; Wed, 7 Feb 1996 
09:45:03 -0800 
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21); 
7 Feb 96 09:55:17 PST8PDT 
Received: from SpoolDir by FRL (Mercury 1.21); 7 Feb 96 09:54:58 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Wed, 7 Feb 1996 09:54:49 -0800 
Subject: SLOW BPSK NEWS 
Priority: normal 
X-mailer: Pegasus Mail v3.22 
Message-ID: <1D82CB45456@frl.orst.edu> 


Hi all, 
Some exciting news that we want to share. 


Pawel, SP9VRC is presently at CERN, Switzerland, and have been patiently 
listening for my (KC7WW, Monroe, Oregon) slow speed BPSK transmissions on 
20 meters. My setup consists of a DSP56002EVM running Pawel's SLOWBPSK 
program, an an ICOM 751 on LSB mode, RF output is 10W to a Butternut 
vertical. 


For the first time; yesterday looked like Pawel got something - not yet 
confirming callsigns, but that is only a matter of time. Here is what he 
e-mailed me: 


Well, this time something did work. Today at 16:20 UTC I got a long lock 


(I didn't need to wait long for it) and then in the garbage characters 
I could clearly see CQ (with capital letters) being sent at least four 
times. 

They were not in a row but at a distance of some 60-80 characters. 

I could see as well the space before or after them. 


I was listenning with the TS-440 and I used the narrow filter 

(I didn't try the wide filter at that time). I was not able to 

hear any audible signal by ear. 

However, I noticed there is some weak but regular CW being sent on this 
or close frequency - it that you ? 


I left the setup running and the output is being recorded on a file. 
I will send you the file later. 

I have made a schedule at 20:00 UTC on 14.180 USB voice with Danie 
every day this week and weekend. 


I'm sure I would capture more text if we had the FEC and good block-sync. 
With asynchronous transmition one fake bit can spoil several 
characters... 


Pawel 


Sounds like fun, does'nt it ? 


--Johan, KC7WW 


From cbuttsch@slonet.org Wed Feb 07 20:29:34 1996 

Received: from biggulp.callamer.com (cbuttsch@biggulp.callamer.com [199.74.141.2]) 
by tapr.org (8.7.3/8.7.2) with SMTP id UAA05105 for <hfsig@tapr.org>; Wed, 7 Feb 
1996 20:29:31 -0600 (CST) 

Received: (from cbuttsch@localhost) by biggulp.callamer.com (8.6.12/8.6.9- 
callamer-rdw080995) id SAA16148; Wed, 7 Feb 1996 18:25:53 -0800 

Date: Wed, 7 Feb 1996 18:25:52 -0800 (PST) 

From: Clifford Buttschardt <cbuttsch@slonet.org> 

To: Johan Forrer <FORRERJ@frl.orst.edu> 

cc: hfsig@tapr.org 

Subject: Re: [HFSIG:853] SLOW BPSK NEWS 

In-Reply-To: <1D82CB45456@frl.orst.edu> 

Message-ID: <Pine.OSF.3.91.960207182038 .13730B-100000@biggulp.callamer.com> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi Johan. Congratulations on the slow speed BPSK experiments. First, I 
was not aware that you had these going on twenty meters. As you know, the 
one watt BPSK beacon is running on 187.65 KHz in the experimenters band. 
It was printed out 1600 miles---San Luis Obispo, CA to Aitkin, Minn. 

I mention this simply to emphasize a great deal is being done and 
even I seem not able to keep up! 73 Cliff Buttschardt W6HDO 


From jbloom@arrl.org Thu Feb 08 10:08:51 1996 


Received: from mgate.arrl.org (root@mgate.arrl.org [205.217.201.2]) by tapr.org 
(8.7.3/8.7.2) with SMTP id KAAQ8028 for <hfsig@tapr.org>; Thu, 8 Feb 1996 10:08:48 
-Q600 (CST) 
Received: from home by mgate.arrl.org with smtp 
(Smail3.1.29.1 #3) id mOtkYpe-OQORANC; Thu, 8 Feb 96 11:04 EST 
Received: by home with Microsoft Mail 
id <O01BAF615.CF258A40@home>; Thu, 8 Feb 1996 11:08:43 -0500 
Message-ID: <0Q1BAF615.CF258A40@home> 
From: Jon Bloom <jbloom@arrl.org> 
To: "'hfsig@tapr.org'" <hfsig@tapr.org> 
Subject: FW: demodulator for MSK signals 
Date: Thu, 8 Feb 1996 11:08:42 -0500 
MIME-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Content-Transfer-Encoding: 7bit 


Can any of you HFSIG gurus help this fellow? 


-- Jon, KE3Z 
jbloom@arrl.org 


From: Mr. Brooke Clarke[SMTP: brooke@pacific.net] 
Sent: Wednesday, February 07, 1996 11:25 PM 

To: jbloom@arrl.org 

Subject: demodulator for MSK signals 


I have been studying Chapter 18 of the '96 Handbook. I would like to buy 
or if not available build a DSP demodulator that can demodulate the MSK 
signals on the Coast Guard LF beacon stations. These stations are 
transmitting Differential Global Positioning System (DGPS) data. 


The lower cost MSK receivers on the market use FSK demodulators. My 
application for the signals is inland where the signals are weak and I 
believe I need a close to optimal demodulator. I can hear signals from a 
number of beacon stations with my ear so expect that a true MSK 
demodulator would give me usable data. 


Could you point me toward a commercial product, a ham type kit, or 
further reading material? 


Thanks, 
Brooke 
N6GCE 


From mwheatle@TRSystems.com Thu Feb 08 10:14:48 1996 
Received: from www (www.trsystems.com [206.232.131.2]) by tapr.org (8.7.3/8.7.2) 
with SMTP id KAAQ8175 for <hfsig@tapr.org>; Thu, 8 Feb 1996 10:14:45 -Q600 (CST) 
Received: by www with Microsoft Mail 

id <01BAF616.BF4232D0@www>; Thu, 8 Feb 1996 11:15:26 -0500 


Message-ID: <c=US%a=_%p=TRSystems%1=WEBSERVER960208111516AX006D00@www> 
From: "Wheatley, Maurice" <mwheatle@TRSystems.com> 

To: "'hfsig'" <hfsig@tapr.org> 

Subject: DSP Tools 

Date: Thu, 8 Feb 1996 11:15:13 -0500 

MIME-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 
Content-Transfer-Encoding: quoted-printable 


Hi everybody, 

I'm new to the SIG and just getting into this interesting DSP stuff. Was= 
wondering if anybody has any suggestions on software design/simulation p= 
ackages for dsp designs that don't require a second mortgage on the house= 
a) 

I've got Math CAD and am looking at QEDesign. 

Also how about book recommendations. Best I've found so far is Marvin Fre= 
rking's "Digital Signal Processing in Communications Systems". 

Any thoughts or referals to past threads would be appreciated. Thanks! 


Moe AE4JY 
mwheatle@trsystems.com 


From chbrain@dircon.co.uk Thu Feb 08 12:39:20 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
tapr.org (8.7.3/8.7.2) with SMTP id MAA14462 for <hfsig@tapr.org>; Thu, 8 Feb 1996 
12:39:10 -Q600 (CST) 
Received: by felix.dircon.co.uk id AA15851 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 8 Feb 1996 18:37:48 GMT 
Message-Id: <199602081837 .AA15851@felix.dircon.co.uk> 
Received: from gw2-193.pool.dircon.co.uk(194.112.35.193) by amnesiac via smap 
(V1.3) 
id sma015653; Thu Feb 8 18:35:39 1996 
X-Sender: chbrain@popmail.dircon.co.uk 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Thu, 08 Feb 1996 18:07:19 +0000 
To: hfsig@tapr.org 
From: chbrain@dircon.co.uk (Charles Brain) 
Subject: Re: [HFSIG:856] DSP Tools 


>Hi everybody, 

>I'm new to the SIG and just getting into this interesting DSP stuff. Was 
wondering if anybody has any suggestions on software design/simulation 
packages for dsp designs that don't require a second mortgage on the house: -) 
>I've got Math CAD and am looking at QEDesign. 

>Also how about book recommendations. Best I've found so far is Marvin 
Frerking's "Digital Signal Processing in Communications Systems". 

>Any thoughts or referals to past threads would be appreciated. Thanks! 

> 

>Moe AE4JY 

>mwheatle@trsystems.com 

> 


> 
Hello Moe, 


Well I use PC-DSP and PC-SIM to design filters etc cost about $200 
there www page is :- 


http: //www.dspsolutions.com 


I am working on modifying some HF channel simulator code written by 
Eric Johnson of NMSU so I can call it from within the package. 


Regards Charles G4GUO 


From srbible@mindport.net Thu Feb 08 18:15:45 1996 

Received: from polaris.mindport.net (root@polaris.mindport.net [205.219.167.2]) by 
tapr.org (8.7.3/8.7.2) with SMTP id SAA29699 for <hfsig@tapr.org>; Thu, 8 Feb 1996 
18:15:38 -0600 (CST) 

Received: from polaris.mindport.net (synapse-12.mindport.net [205.219.167.31]) by 
polaris.mindport.net (8.6.12/8.6.12) with SMTP id TAA27985 for <hfsig@tapr.org>; 
Thu, 8 Feb 1996 19:15:35 -0500 

Date: Thu, 8 Feb 1996 19:15:35 -0500 

Posted-Date: Thu, 8 Feb 1996 19:15:35 -0500 

Message-Id: <199602090015.TAA27985@polaris.mindport.net> 

X-Sender: srbible@mail.mindport.net 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: srbible@mindport.net (Steven R. Bible) 

Subject: Re: [HFSIG:856] DSP Tools 


>Hi everybody, 

>I'm new to the SIG and just getting into this interesting DSP stuff. Was 
wondering if anybody has any suggestions on software design/simulation 
packages for dsp designs that don't require a second mortgage on the house:-) 
>I've got Math CAD and am looking at QEDesign. 

>Also how about book recommendations. Best I've found so far is Marvin 
Frerking's "Digital Signal Processing in Communications Systems". 

>Any thoughts or referals to past threads would be appreciated. Thanks! 


Hello Moe, 

I really enjoy the Frerking Book. I am still studying it and I would like 
to construct a DSP based receiver. Both Harris and ADI have chips that are 
designed for digital IF. 


Harris - http://www.semi.harris.com/ 


AN9509.1 Digital IF Sub Sampling Using the HI5702, HSP45116 
and HSP43220 


HSP50016 Digital Down Converter 


TB330 Higher Speed Clock Rates Help Ease Filtering Requirements 
in Communication D/As 


AN9401 Reducing the Minimum Decimation Rate of the HSP50016 
Digital Down Converter 


Analog Devices - http://www.analog.com/ 
ADSP-21060/ADSP-21062 Super Harvard Architecture Computers 


The Frerking Book does an excellent job of bringing you up from digital 
basics to digital communications (not data communications which usually 
refers to LAN based protocols). 


I spent some time surfing the web for books. I created a temporary 
bibliography of books on Spread Spectrum, DSP, Digital Communications, and 
MATLAB. You can take a look at: 


http: //www.mindport.net/~srbible/biblio. html 


I will be moving this page to the www.tapr.org site soon. In the mean time, 
please take a look and give comments. You can see the books that I have 
found in the above catagories. You can click on the titles and you will go 
to the publishers web pages that describes the books in detail. I have also 
included some technical bookstores at the bottom of the page. I have had 
excellent results with the San Diego Technical Bookstore (no peculinary 
interest, just a happy customer). 


As for DSP development platforms. Both TI (www.ti.com) and Motorola 
(www.motorola.com) have inexpensive DSP Starter Kits (DSK) (TI) or 
Evaluation Modules (EVM) (Motorola). The TI C5X DSK (p/n TMDS3200051) costs 
$99.00 and the Motorola EVM560002 costs $149.00. I own the later and have 
the former on order. 


The best place to read about the EVM56002 is Johan Forrer's KC7WW August 
1995 QEX article (you can order back issues from the ARRL). (BTW - Johan 
moderates this list. Thanks for the article Johan!) 


As for matimatical simulators, there's PC-DSP for which you can download an 
evaluation copy from the 'net (http://www.dspsolutions.com/), and there's 
MATLAB. There's a book entitled "Digital Signal Processing: A Laboratory 
Approach Using PC-DSP, 2/e" (see my biblio web page). There's also another 
book for MATLAB entitled "Computer-Based Exercises for Signal Processing 
Using MATLAB, 1/e." 


Hope this helps. 
73, 
- Steve, N7HPR 


srbible@mindport.net 
n7hpr@amsat.org 


n7hpr@tapr. org 


From ssykes@ns2.emirates.net.ae Fri Feb 09 02:49:57 1996 
Received: from ns2.emirates.net.ae (ns2.emirates.net.ae [194.170.1.7]) by tapr.org 
(8.7.3/8.7.2) with SMTP id CAA25565 for <hfsig@tapr.org>; Fri, 9 Feb 1996 02:49:52 
-Q600 (CST) 
Received: from csaQ29.emirates.net.ae by ns2.emirates.net.ae (5.x/SMI- 
SVR495081401) 
id AC26511; Fri, 9 Feb 1996 12:49:44 +0400 
Message-Id: <9602090849.AC26511@ns2.emirates.net.ae> 
X-Sender: ssykes@emirates.net.ae 
X-Mailer: Windows Eudora Light Version 1.5.2 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Fri, 09 Feb 1996 12:46:26 +0400 
To: hfsig@tapr.org 
From: Stephan Sykes <ssykes@ns2.emirates.net.ae> 
Subject: Re: [HFSIG:853] SLOW BPSK NEWS 


What frequency on 20 are you using? 


At 11:50 AM 2/7/96 -0600, you wrote: 

>Hi all, 

> 

>Some exciting news that we want to share. 

> 

>Pawel, SPOVRC is presently at CERN, Switzerland, and have been patiently 
>listening for my (KC7WW, Monroe, Oregon) slow speed BPSK transmissions on 
>20 meters. My setup consists of a DSP56002EVM running Pawel's SLOWBPSK 
>program, an an ICOM 751 on LSB mode, RF output is 10W to a Butternut 
>vertical. 

> 

>For the first time; yesterday looked like Pawel got something - not yet 
>confirming callsigns, but that is only a matter of time. Here is what he 
>e-mailed me: 

> 

Se a te cetera ee ad a el 

>Well, this time something did work. Today at 16:20 UTC I got a long lock 
>(I didn't need to wait long for it) and then in the garbage characters 
>I could clearly see CQ (with capital letters) being sent at least four 
>times. 

>They were not in a row but at a distance of some 60-80 characters. 

>I could see as well the space before or after them. 

> 

>I was listenning with the TS-440 and I used the narrow filter 

>(I didn't try the wide filter at that time). I was not able to 

>hear any audible signal by ear. 

>However, I noticed there is some weak but regular CW being sent on this 
>or close frequency - it that you ? 

> 

>I left the setup running and the output is being recorded on a file. 

>I will send you the file later. 

>I have made a schedule at 20:00 UTC on 14.180 USB voice with Danie 


>every day this week and weekend. 

> 

>I'm sure I would capture more text if we had the FEC and good block-sync. 
>With asynchronous transmition one fake bit can spoil several 
>characters... 

> 

>Pawel 

> weeeeewene eee ewww eww ew we we = 

> 

>Sounds like fun, does'nt it ? 

> 

>--Johan, KC7WW 

> 

> 

> 

Stephan Sykes 

ssykes@emirates.net.ae 


From forrerj@ucs.orst.edu Fri Feb 09 10:39:10 1996 
Received: from ucs.orst.edu (forrerj@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.3/8.7.2) with SMTP id KAA13593 for <hfsig@tapr.org>; Fri, 9 Feb 1996 10:39:07 
-Q600 (CST) 
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM) 
id AA11287; Fri, 9 Feb 1996 08:38:54 -0800 
Date: Fri, 9 Feb 1996 08:38:53 -0800 (PST) 
From: Johan Forrer <forrerj@ucs.orst.edu> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:859] Re: SLOW BPSK NEWS 
In-Reply-To: <9602090849.AC26511@ns2.emirates.net.ae> 
Message-Id: <Pine.OSF.3.91.960209083439 .28524A-100000@ucs.orst.edu> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi Stephen, 


We are on 14.100, closeby the international CW beacon frequency. Set 

your dial for a readout of 14.100 on LSB mode. The actual carrier is some 
1650 Hz lower down from 14.100. Use the CW beacons as a reference for 
propation status. 


The beacon is on for a few hours between about 12.00 - 20.00 UTC. I can 
arrange to have it on for other periods as well. 


73's 


--Johan, KC7WW 


On Fri, 9 Feb 1996, Stephan 
Sykes wrote: 


VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV 


What frequency on 20 are you using? 


At 11:50 AM 2/7/96 -0600, you wrote: 

>Hi all, 

> 

>Some exciting news that we want to share. 

> 

>Pawel, SPOVRC is presently at CERN, Switzerland, and have been patiently 
>listening for my (KC7WW, Monroe, Oregon) slow speed BPSK transmissions on 
>20 meters. My setup consists of a DSP56002EVM running Pawel's SLOWBPSK 
>program, an an ICOM 751 on LSB mode, RF output is 10W to a Butternut 
>vertical. 

> 

>For the first time; yesterday looked like Pawel got something - not yet 
>confirming callsigns, but that is only a matter of time. Here is what he 
>e-mailed me: 

> 

a ges a ee ee ae ee ere 

>Well, this time something did work. Today at 16:20 UTC I got a long lock 
>(I didn't need to wait long for it) and then in the garbage characters 
>I could clearly see CQ (with capital letters) being sent at least four 
>times. 

>They were not in a row but at a distance of some 60-80 characters. 

>I could see as well the space before or after them. 

> 

>I was listenning with the TS-440 and I used the narrow filter 

>(I didn't try the wide filter at that time). I was not able to 

>hear any audible signal by ear. 

>However, I noticed there is some weak but regular CW being sent on this 
>or close frequency - it that you ? 

> 

>I left the setup running and the output is being recorded on a file. 

>I will send you the file later. 

>I have made a schedule at 20:00 UTC on 14.180 USB voice with Danie 
>every day this week and weekend. 

> 

>I'm sure I would capture more text if we had the FEC and good block-sync. 
>With asynchronous transmition one fake bit can spoil several 
>characters... 

> 

>Pawel 

Ce ee Seer ee eee 

> 

>Sounds like fun, does'nt it ? 

> 

>--Johan, KC7WW 

> 

> 

> 

Stephan Sykes 

ssykes@emirates.net.ae 


From mwheatle@TRSystems.com Fri Feb 09 14:24:44 1996 
Received: from www (www.trsystems.com [206.232.131.2]) by tapr.org (8.7.3/8.7.2) 
with SMTP id 0AA22566 for <hfsig@tapr.org>; Fri, 9 Feb 1996 14:24:41 -Q600 (CST) 
Received: by www with Microsoft Mail 
id <Q1BAF702.D3E81EBO@www>; Fri, 9 Feb 1996 15:25:22 -0500 
Message-ID: <c=US%a=_%p=TRSystems%1=WEBSERVER960209152514AB005400@www> 
From: "Wheatley, Maurice" <mwheatle@TRSystems.com> 
To: "'hfsig'" <hfsig@tapr.org> 
Subject: TNX for help 
Date: Fri, 9 Feb 1996 15:25:11 -0500 
MIME-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Content-Transfer-Encoding: quoted-printable 


Thanks to Charles and Steven for the help. The 

http: //www.mindport.net/~srbible/biblio.html site is a great launching po= 
int 

for technical book sources. Now to figure out how to funnel all that inf= 
ormation into my head so I can contribute something useful someday. Thank= 
S again. 


Moe AE4JY 
mwheatle@trsystems.com 


From forrerj@ucs.orst.edu Sat Feb 10 23:05:08 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.3/8.7.2) with SMTP id XAA07574 for <hfsig@tapr.org>; Sat, 10 Feb 1996 
23:05:05 -0600 (CST) 
Received: from p01.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/24Sep94-1201PM) 
id AA20014; Sat, 10 Feb 1996 21:04:24 -0800 
Message-Id: <9602110504.AA20014@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Sat, 10 Feb 1996 21:08:37 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: HF channel simulator 
Cc: kurpiers@zeus.uet.e-technik.th-darmstadt.de 


Dear Alexander, 


Thank you very much for your posting of the HF channel simulator. It looks 
like a wonderful tool and I am sure we are only at the very beginning of 
this kind of exploration, at least as amateurs. 

Fortunately for me, the bit of comments in German was no problem. 


I looked a bit at the code and have a few questions that I would appreciate 
your comments: Which assembler was used? It obviously is not the DSK 


assembler because that cannot even handle simple directives such as ".equ" 
or compound statements such as "label+4". I did tried Speech Corporation's 
TASM for the 320C25 as used with the DSP93, but that terminates in error 
because of some internal table overflow. (If anyone could tell me how to 
increase the size of the "bpoutp" I would be grateful). 


Do you perhaps know of a PD assembler that would assemble the program? 


The other bit of information that would be quite useful to know beforehand 
is the memory requirements. It so happens that I also have an LED bargraph 
at port 0 and external program memory located at 1000-EFFFh, so I may just 
be lucky to be able to run the simulator on my platform without too much 
problems. 


Thanks again for your valued contribution. 
--Johan, KC7WW 


From danie.brynard@pixie.co.za Sun Feb 11 02:44:51 1996 

Received: from £15.pix.za (root@£15.pix.za [196.11.62.108]) by tapr.org 
(8.7.3/8.7.2) with ESMTP id CAA20596 for <hfsig@tapr.org>; Sun, 11 Feb 1996 
02:44:43 -0600 (CST) 

Received: from net-13.pta.pix.za (net-3.pta.pix.za [196.11.63.3]) by £15.pix.za 
(8.7.1/8.6.11) with SMTP id KAA18842 for <hfsig@tapr.org>; Sun, 11 Feb 1996 
10:46:47 +0200 

Message-Id: <199602110846.KAA18842@£15.pix.za> 

X-Sender: pak03226@pixie.co.za 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sun, 11 Feb 1996 10:44:26 +0200 

To: hfsig@tapr.org 

From: danie.brynard@pixie.co.za (Danie Brynard) 

Subject: Re: [HFSIG:853] SLOW BPSK NEWS 


REGARDING SLOW BPSK between CERN and Pretoria (ZS): 


Well all I can report is that we have not been successfull yet :-( If there 
are any other guys interested in working SLOW BPSK with me let me know 
please ! I can work the east coast of the USA quite easily but the west 
coast seems to be a problem. (were Johan kc7ww is) 


I can also hear the Italians VERY often so are their any Italian SLOW BPSK 
guys out there ? 


73 Danie zs6éawk 


>Hi all, 

> 

>Some exciting news that we want to share. 

> 

>Pawel, SP9VRC is presently at CERN, Switzerland, and have been patiently 
>listening for my (KC7WW, Monroe, Oregon) slow speed BPSK transmissions on 


>20 meters. My setup consists of a DSP56002EVM running Pawel's SLOWBPSK 
>program, an an ICOM 751 on LSB mode, RF output is 10W to a Butternut 
>vertical. 

> 

>For the first time; yesterday looked like Pawel got something - not yet 
>confirming callsigns, but that is only a matter of time. Here is what he 
>e-mailed me: 

> 

Seg sa et Ret a elaine ee 

>Well, this time something did work. Today at 16:20 UTC I got a long lock 
>(I didn't need to wait long for it) and then in the garbage characters 
>I could clearly see CQ (with capital letters) being sent at least four 
>times. 

>They were not in a row but at a distance of some 60-80 characters. 

>I could see as well the space before or after them. 

> 

>I was listenning with the TS-440 and I used the narrow filter 

>(I didn't try the wide filter at that time). I was not able to 

>hear any audible signal by ear. 

>However, I noticed there is some weak but regular CW being sent on this 
>or close frequency - it that you ? 

> 

>I left the setup running and the output is being recorded on a file. 

>I will send you the file later. 

>I have made a schedule at 20:00 UTC on 14.180 USB voice with Danie 
>every day this week and weekend. 

> 

>I'm sure I would capture more text if we had the FEC and good block-sync. 
>With asynchronous transmition one fake bit can spoil several 
>characters... 

> 

>Pawel 

Sof 8 SR LCE LOR Soa 

> 

>Sounds like fun, does'nt it ? 

> 

>--Johan, KC7WW 

> 

> 

> 


From danie.brynard@pixie.co.za Sun Feb 11 02:45:08 1996 

Received: from £15.pix.za (root@£15.pix.za [196.11.62.108]) by tapr.org 
(8.7.3/8.7.2) with ESMTP id CAA20615 for <hfsig@tapr.org>; Sun, 11 Feb 1996 
02:44:56 -0600 (CST) 

Received: from net-13.pta.pix.za (net-3.pta.pix.za [196.11.63.3]) by £15.pix.za 
(8.7.1/8.6.11) with SMTP id KAA18851 for <hfsig@tapr.org>; Sun, 11 Feb 1996 
10:47:10 +0200 

Message-Id: <199602110847 .KAA18851@£15.pix.za> 

X-Sender: pak03226@pixie.co.za 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 


Date: Sun, 11 Feb 1996 10:44:45 +0200 

To: hfsig@tapr.org 

From: danie.brynard@pixie.co.za (Danie Brynard) 
Subject: Re: [HFSIG:856] DSP Tools 


The ALEFNULL stuff at nic.funet.fi is a good start ! Matlab is also a good 
analysis tool. There is a student version out. The next step is to get a 
DSP56002EVM ..... 73 danie zs6awk 


>Hi everybody, 

>I'm new to the SIG and just getting into this interesting DSP stuff. Was 
wondering if anybody has any suggestions on software design/simulation 
packages for dsp designs that don't require a second mortgage on the house: -) 
>I've got Math CAD and am looking at QEDesign. 

>Also how about book recommendations. Best I've found so far is Marvin 
Frerking's "Digital Signal Processing in Communications Systems". 

>Any thoughts or referals to past threads would be appreciated. Thanks! 

> 

>Moe AE4JY 

>mwheatle@trsystems.com 

> 

> 


From danie.brynard@pixie.co.za Sun Feb 11 02:45:23 1996 

Received: from £15.pix.za (root@£15.pix.za [196.11.62.108]) by tapr.org 
(8.7.3/8.7.2) with ESMTP id CAA20627 for <hfsig@tapr.org>; Sun, 11 Feb 1996 
02:45:08 -0600 (CST) 

Received: from net-13.pta.pix.za (net-3.pta.pix.za [196.11.63.3]) by £15.pix.za 
(8.7.1/8.6.11) with SMTP id KAA18857 for <hfsig@tapr.org>; Sun, 11 Feb 1996 
10:47:27 +0200 

Message-Id: <199602110847 .KAA18857@£15.pix.za> 

X-Sender: pak03226@pixie.co.za 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sun, 11 Feb 1996 10:45:02 +0200 

To: hfsig@tapr.org 

From: danie.brynard@pixie.co.za (Danie Brynard) 

Subject: Re: [HFSIG:859] Re: SLOW BPSK NEWS 


>What frequency on 20 are you using? 
> 


I can be on 14.168 SSB/CW and 14.065 SBPSK if somebody want to try slow 
bpsk. A typical time suitable for me is 20Q0UTC. Let me know .... 73 danie 
zs6awk 


BRYD@KIDD.CO.ZA 


From danie.brynard@pixie.co.za Sun Feb 11 02:45:49 1996 

Received: from £15.pix.za (root@£15.pix.za [196.11.62.108]) by tapr.org 
(8.7.3/8.7.2) with ESMTP id CAA20639 for <hfsig@tapr.org>; Sun, 11 Feb 1996 
02:45:17 -0600 (CST) 


Received: from net-13.pta.pix.za (net-3.pta.pix.za [196.11.63.3]) by £15.pix.za 
(8.7.1/8.6.11) with SMTP id KAA18860 for <hfsig@tapr.org>; Sun, 11 Feb 1996 
10:47:32 +0200 

Message-Id: <199602110847 .KAA18860@£15.pix.za> 

X-Sender: pak03226@pixie.co.za 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sun, 11 Feb 1996 10:45:05 +0200 

To: hfsig@tapr.org 

From: danie.brynard@pixie.co.za (Danie Brynard) 

Subject: Re: [HFSIG:860] Re: SLOW BPSK NEWS 


Johan how did you determine the optimum audio level input for your SBPSK 
demod ? Danie zs6awk BRYD@KIDD.CO.ZA 


>Hi Stephen, 

> 

> 

>We are on 14.100, closeby the international CW beacon frequency. Set 
>your dial for a readout of 14.100 on LSB mode. The actual carrier is some 
>1650 Hz lower down from 14.100. Use the CW beacons as a reference for 
>propation status. 

> 

>The beacon is on for a few hours between about 12.00 - 20.00 UTC. I can 
>arrange to have it on for other periods as well. 


> 
>73's 

> 

>--Johan, KC7WW 
> 


From Hakan.Bergzen@telub.se Sun Feb 11 06:01:53 1996 
Received: from terminus.inforum.telub.se (terminus. inforum.telub.se 
[147.13.12.199]) by tapr.org (8.7.3/8.7.2) with SMTP id GAA26187 for 
<hfsig@tapr.org>; Sun, 11 Feb 1996 06:01:47 -0600 (CST) 
Received: from noak.vxo.telub.se by terminus.inforum.telub.se with SMTP (PP) 
id <11381-0@terminus.inforum.telub.se>; 
Sun, 11 Feb 1996 13:01:07 +0100 
Received: by noak with Microsoft Mail id <3128E503@noak>; 
Sun, 11 Feb 96 13:00:51 GMT 
From: "Bergzen Hakan, KARL" <Hakan.Bergzen@telub.se> 
To: HFSIG at TAPR <hfsig@tapr.org> 
Subject: HF channel simulator 
Date: Sun, 11 Feb 96 12:55:00 GMT 
Message-ID: <3128E503@noak> 
Return-Receipt-To: HABE <Hakan.Bergzen@telub.se> 
Encoding: 36 TEXT 
X-Mailer: Microsoft Mail V3.0 
MIME-Version: 1.0 
Content-Type: Text/plain; charset="US-ASCII" 
Content-Transfer-Encoding: 7bit 


Hello, 


This week I participated (only passively though) in a very good HF 
conference, or colloquium as they call it just to make it tricky to 
pronounciate and spell ;-). It was called 'HF frequency selection and 
management techniques for HF communications', and was held in London and 
arranged by the IEE. 


It addresses several topics of interest to this group, e.g. the DAMSON 
northern latitude ionospheric measurement project, NATO work on developing a 
new robust waveform to handle those extreme conditions (as measured by 
DAMSON) and development of adaptive HF systems (and standardization 
thereof). 


I will, however, mention two other topics of interest: 


1. The next ITU frequency conference (I don't know if it really is called a 
conference) will discuss a Swedish proposal of using frequency block 
allocations on MF and HF wavelengths thus enabling truly efficient use of 
the new adaptive HF systems. (The situation today seems to be quite chaotic) 
A paper by L W Barcaly called 'A changed regulatory environment for the HF 
services’ addressed this. I guess you could say that the amateur radio 
allocations are the truly first block allocations. 


2. Tricia Willink of the Communications Research Centre in Ottawa presented 
their work on validating HF channel simulators being developed by both them 
and the UK Defence Research Agency. The paper is called ‘Validation of HF 
channel simulators'. These were very thorough and professional tests and I 
would think it wise to consider a likewise approach if an HF channel 
simulator would be developed within this group (e.g. based on Alexander's 
simulator). Thus we could truly say that it behaves as expected. 


A brief report from 
Hakan (hakan.bergzen@telub.se) 


From karn@qualcomm.com Sun Feb 11 20:44:45 1996 

Received: from zeus.qualcomm.com (zeus.qualcomm.com [129.46.50.42]) by tapr.org 
(8.7.3/8.7.2) with ESMTP id UAA11983 for <hfsig@tapr.org>; Sun, 11 Feb 1996 
20:44:39 -0600 (CST) 

Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by zeus.qualcomm.com 
(8.7.3/8.7.2/1.4) with ESMTP id SAA15577 for <hfsig@tapr.org>; Sun, 11 Feb 1996 
18:44:06 -0800 (PST) 

Received: from laptop.qualcomm.com (laptop.ka9q.ampr.org [129.46.90.37]) by 
qualcomm.com with SMTP id SAA12131 for <hfsig@tapr.org>; Sun, 11 Feb 1996 
18:44:50 -0800 (PST) 

Date: Sun, 11 Feb 1996 18:44:50 -0800 (PST) 

Message-Id: <199602120244 .SAA12131@qualcomm. com> 

X-Sender: karn@servo.qualcomm.com (Unverified) 

X-Mailer: Windows Eudora Pro Version 2.1.2 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 


To: hfsig@tapr.org 
From: Phil Karn <karn@qualcomm. com> 
Subject: Re: [HFSIG:858] Re: DSP Tools 


At 06:22 PM 2/8/96 -0600, you wrote: 


>As for DSP development platforms. Both TI (www.ti.com) and Motorola 
>(www.motorola.com) have inexpensive DSP Starter Kits (DSK) (TI) or 
>Evaluation Modules (EVM) (Motorola). The TI C5X DSK (p/n TMDS3200051) costs 
>$99.00 and the Motorola EVM560002 costs $149.00. I own the later and have 
>the former on order. 


Don't forget that you can do serious DSP on general purpose computers without 
a DSP board. Pentiums and the faster 486s rival many dedicated DSPs, especially 
on floating point computations. 


Phil 


From danie.brynard@pixie.co.za Sun Feb 11 23:07:04 1996 

Received: from £15.pix.za (root@£15.pix.za [196.11.62.108]) by tapr.org 
(8.7.3/8.7.2) with ESMTP id XAA17920 for <hfsig@tapr.org>; Sun, 11 Feb 1996 
23:06:59 -0600 (CST) 

Received: from net-14.pta.pix.za (net-14.pta.pix.za [196.11.63.14]) by £15.pix.za 
(8.7.1/8.6.11) with SMTP id HAA14738 for <hfsig@tapr.org>; Mon, 12 Feb 1996 
07:09:25 +0200 

Message-Id: <199602120509.HAA14738@£15.pix.za> 

X-Sender: pak03226@pixie.co.za 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Mon, 12 Feb 1996 07:06:56 +0200 

To: hfsig@tapr.org 

From: danie.brynard@pixie.co.za (Danie Brynard) 

Subject: Re: [HFSIG:868] Re: DSP Tools 


>Don't forget that you can do serious DSP on general purpose computers without 
>a DSP board. Pentiums and the faster 486s rival many dedicated DSPs, especially 
>on floating point computations. 

> 


Sounds exciting Phil. What software is available so far for the satellites ? 
73 Danie 


From hstr@gil.com.au Mon Feb 12 07:36:08 1996 
Received: from iccu6.ipswich.gil.com.au (iccu6.ipswich.gil.com.au [203.1.75.10]) 
by tapr.org (8.7.3/8.7.2) with ESMTP id HAA11464 for <hfsig@tapr.org>; Mon, 12 Feb 
1996 07:36:04 -0600 (CST) 
Received: from cs5p4.ipswich.gil.com.au (cs5p4.ipswich.gil.com.au [203.1.75.33]) 
by iccu6é.ipswich.gil.com.au with SMTP id IAA29492 

(8.6.12/IDA-1.6 for <hfsig@tapr.org>); Mon, 12 Feb 1996 08:35:28 -0500 
Message-ID: <199602121335.IAA29492@iccu6.ipswich.gil.com.au> 


Comments: Authenticated sender is <hstr@mail.ipswich.gil.com.au> 
From: "Helmut Strickner" <hstr@gil.com.au> 


To: 


hfsig@tapr.org 


Date: Mon, 12 Feb 1996 23:35:46 +1000 
Subject: Re: [HFSIG:853] SLOW BPSK NEWS 
Priority: normal 


X- 


> 


mailer: Pegasus Mail for Windows (v2.23) 


Hello Johan, Pawel and all 


good news about the slow BPSK. I would be interested in participating 
in the experiments. Unfortunately the 10 hour time difference between 
VK land and stateside/Europe is a bit of a problem with listening to 
the beacon (also the propagation). Johan I wonder if you could have the 
beacon on weekends when there is propagation to VK4? 

The other question is regarding the modem software, I have not seen 

it as yet, probably Pawel distributed it only to a small group. 

Perhaps I could get a copy too, I would be able to put out a beacon 
from my QTH during some periods of propagation if there is any 
interest. 


Helmut VK4STR 


VV VV VV VV VV VV VV VV VV VV VV VV VV OV 


Hi all, 


Some exciting news that we want to share. 


Pawel, SP9VRC is presently at CERN, Switzerland, and have been patiently 
listening for my (KC7WW, Monroe, Oregon) slow speed BPSK transmissions on 
20 meters. My setup consists of a DSP56002EVM running Pawel's SLOWBPSK 
program, an an ICOM 751 on LSB mode, RF output is 10W to a Butternut 
vertical. 


For the first time; yesterday looked like Pawel got something - not yet 
confirming callsigns, but that is only a matter of time. Here is what he 
e-mailed me: 


Well, this time something did work. Today at 16:20 UTC I got a long lock 
(I didn't need to wait long for it) and then in the garbage characters 

I could clearly see CQ (with capital letters) being sent at least four 
times. 

They were not in a row but at a distance of some 60-80 characters. 

I could see as well the space before or after them. 


I was listenning with the TS-440 and I used the narrow filter 

(I didn't try the wide filter at that time). I was not able to 

hear any audible signal by ear. 

However, I noticed there is some weak but regular CW being sent on this 
or close frequency - it that you ? 


I left the setup running and the output is being recorded on a file. 

I will send you the file later. 

I have made a schedule at 20:00 UTC on 14.180 USB voice with Danie 

every day this week and weekend. 

I'm sure I would capture more text if we had the FEC and good block-sync. 
With asynchronous transmition one fake bit can spoil several 
characters... 

Pawel 


Sounds like fun, does'nt it ? 


--Johan, KC7WW 


VV VV VV VV VV VV VV VV VV OV 


From dona@tridelta.com Mon Feb 12 08:43:35 1996 

Received: from wariat.wariat.org (uucp@wariat.wariat.org [192.147.147.1]) by 
tapr.org (8.7.3/8.7.2) with ESMTP id IAA14638 for <hfsig@tapr.org>; Mon, 12 Feb 
1996 08:43:33 -0600 (CST) 

Received: from tridelta.com (uucp@localhost) by wariat.wariat.org (8.6.12/8.6.9) 
with UUCP id JAA02850 for hfsig@tapr.org; Mon, 12 Feb 1996 09:43:31 -0500 
Received: from sparcy.tridelta.com (sparcy [192.160.168.222]) by tdi3.tridelta.com 
(8.6.9/8.6.9) with ESMTP id JAA12383 for <hfsig@tapr.org>; Mon, 12 Feb 1996 
09:15:50 -0500 

Received: from donapc.tridelta.com (donapc.tridelta.com [192.160.168.70]) by 
sparcy.tridelta.com (8.7.1/8.7.1) with SMTP id JAA24420 for <hfsig@tapr.org>; Mon, 
12 Feb 1996 09:14:56 -0500 (EST) 

Date: Mon, 12 Feb 1996 09:14:56 -0500 (EST) 

Message-Id: <199602121414. JAA24420@sparcy.tridelta. com> 

X-Sender: dona@sparcy 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: dona@tridelta.com (Don Adams) 

Subject: Re: [HFSIG:866] Re: SLOW BPSK NEWS 


Where's the spec's on the format Ur using for this slow bsk? 
(I've read most of the archives but I must have missed it) 


over and out’ don WA8QZZ 


From FORRERJ@frl.orst.edu Mon Feb 12 10:52:04 1996 

Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
tapr.org (8.7.3/8.7.3/1.8) with SMTP id KAA20861 for <hfsig@tapr.org>; Mon, 12 Feb 
1996 10:51:59 -0600 (CST) 

Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id IAA12272 for <hfsig@tapr.org>; Mon, 12 Feb 1996 


08:48:45 -0800 

Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21); 
12 Feb 96 08:59:10 PST8PDT 

Received: from SpoolDir by FRL (Mercury 1.21); 12 Feb 96 08:59:07 PST8PDT 

From: "Johan Forrer" <FORRERJ@frl.orst.edu> 

Organization: Forest Research Lab. Oregon State 

To: hfsig@tapr.org 

Date: Mon, 12 Feb 1996 08:59:04 -0800 

Subject: Re: [HFSIG:870] Re: SLOW BPSK NEWS 

Priority: normal 

X-mailer: Pegasus Mail v3.22 

Message-ID: <24F41D42498@frl.orst.edu> 


Hello Helmuth, 


I would be happy to put the beacon on for longer/different periods and that 
would be nice to get your participating in listening. Which times would you 
suggest trying? 


This weekend I heard the JA CW beacon in the late afternoons, so I 
suppose there is propagation towards the east. 


When I get home tonight I'll forward you my copy of SLOWBPSK. I am in the 
process of putting together an updated collection of items for the EVM 

for use on HF - that will probably be ready in the near future. This 
includes some new stuff for the 66/80 MHz EVM. I will ask Pawel whether it 
is OK for me to include his latest code. These are the PSK 
terrestrial/satellite modems and the SLOWBPSK. I also have had excellent 
results using his FAX/SSTV DSP modem. 


Till later, 
--Johan, KC7WW 


From FORRERJ@frl.orst.edu Mon Feb 12 11:01:11 1996 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
tapr.org (8.7.3/8.7.3/1.8) with SMTP id LAA21212 for <hfsig@tapr.org>; Mon, 12 Feb 
1996 11:01:08 -0600 (CST) 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id IAA12322 for <hfsig@tapr.org>; Mon, 12 Feb 1996 
08:57:53 -0800 
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21); 
12 Feb 96 09:08:17 PST8PDT 
Received: from SpoolDir by FRL (Mercury 1.21); 12 Feb 96 09:08:02 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Mon, 12 Feb 1996 09:07:57 -0800 
Subject: Re: [HFSIG:871] Re: SLOW BPSK NEWS 
Priority: normal 
X-mailer: Pegasus Mail v3.22 
Message-ID: <24F67D9386A@frl.orst.edu> 


Don, 


The SLOWBPSK format was described in several of Pawel's (SP9VRC) 

postings. There was some discussion about the use and implementation of 
"raised cosine" pulse shaping - if you could locate that, you will see what 
it's about. 


But just to elaborate a bit if I may, it is BPSK at 30 bps. The symbol set 
is straight ASCII. Nothing fancy as far as this is concerned. Wafeform 
shaping and a good demodulator makes the difference. 


Hope this helps. Perhaps Pawel want to elaborate further. How about that 
Pawel? 


--Johan 


From alanb@polecat.sr.hp.com Mon Feb 12 11:18:18 1996 
Received: from hp.com (hp.com [15.255.152.4]) by tapr.org (8.7.3/8.7.3/1.8) with 
ESMTP id LAA22031 for <hfsig@tapr.org>; Mon, 12 Feb 1996 11:18:11 -Q600 (CST) 
Received: from srmail.sr.hp.com by hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AAQ11785476; Mon, 12 Feb 1996 09:17:59 -0800 
Received: from polecat.sr.hp.com by srmail.sr.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AAQ56465471; Mon, 12 Feb 1996 09:17:52 -0800 
Received: by polecat.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AAQQ0935471; Mon, 12 Feb 1996 09:17:51 -0800 
From: Alan Bloom <alanb@polecat.sr.hp.com> 
Message-Id: <199602121717 .AA000935471@polecat.sr.hp.com> 
Subject: DSP processors 
To: hfsig@tapr.org 
Date: Mon, 12 Feb 1996 09:17:50 -0800 (PST) 
X-Mailer: ELM [version 2.4 PL21] 
Mime-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 


Phil Karn <karn@qualcomm.com> wrote: 


>Don't forget that you can do serious DSP on general purpose computers without 
>a DSP board. Pentiums and the faster 486s rival many dedicated DSPs, especially 
>on floating point computations. 


And for non-real-time processing (or for simple low-bandwidth applications) 
you can make do with something a lot less powerful than a Pentium. 


Al N1AL 


From FORRERJ@frl.orst.edu Mon Feb 12 11:19:13 1996 

Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
tapr.org (8.7.3/8.7.3/1.8) with SMTP id LAA22380 for <HFSIG@TAPR.ORG>; Mon, 12 Feb 
1996 11:19:03 -0600 (CST) 

Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id JAA12457 for <HFSIG@TAPR.ORG>; Mon, 12 Feb 1996 
09:15:46 -0800 


Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21); 
12 Feb 96 09:26:11 PST8PDT 

Received: from SpoolDir by FRL (Mercury 1.21); 12 Feb 96 09:26:00 PST8PDT 

From: "Johan Forrer" <FORRERJ@frl.orst.edu> 

Organization: Forest Research Lab. Oregon State 

To: HFSIG@tapr.org 

Date: Mon, 12 Feb 1996 09:25:55 -0800 

Subject: Help with EZKIT 

Priority: normal 

X-mailer: Pegasus Mail v3.22 

Message-ID: <24FB4927CC6@frl.orst.edu> 


Hi, 


I wonder if there is some kind soul that could help me get my EZKITLITE 
going - My second software disk is bad. As far as I can tell, all I need 
is the file “EZKITAPP.EXE" and it is called "EZKITAPP.EX$" on the disk. 


I would greatly appreciate it if someone can e-mail me the file. It is some 
170K, otherwise I have to go the long route to get it replaced. 


Thanks much. 
--Johan 


From cbuttsch@slonet.org Mon Feb 12 12:37:19 1996 

Received: from biggulp.callamer.com (cbuttsch@biggulp.callamer.com [199.74.141.2]) 
by tapr.org (8.7.3/8.7.3/1.8) with SMTP id MAA26409; Mon, 12 Feb 1996 12:37:15 
-Q600 (CST) 

Received: (from cbuttsch@localhost) by biggulp.callamer.com (8.6.12/8.6.9- 
callamer-rdw080995) id KAA19694; Mon, 12 Feb 1996 10:35:56 -0800 

Date: Mon, 12 Feb 1996 10:35:56 -0Q800 (PST) 

From: Clifford Buttschardt <cbuttsch@slonet.org> 

To: Johan Forrer <FORRERJ@frl.orst.edu> 

cc: hfsig@tapr.org, ss@tapr.org 

Subject: Re: [HFSIG:872] Re: SLOW BPSK NEWS 

In-Reply-To: <24F41D42498@frl.orst.edu> 

Message-ID: <Pine.OSF.3.91.960212102003 .1931D-100000@bigsulp.callamer.com> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi Johan. Many thanks for your encouragement regarding the slow speed 
BPSK that we both are doing. I was most interested to see where your are 
using 30 bps ASCII! Since I had no clue, it is refreshing to know this. 
We are using ten bps ASCII also with seven data bits and two stop bits. 
This produces one character persecond. The software is entirely done, 
and in fact improved daily. We started out with 12 samples per bit and 
now are up to 20----the maximum that a 486 computer can analyze real 
time. The system is about to be changed to what is called PSKL which 
stands for Phase Shift Keying Lattice code. Where the 7 bit code and a 
two to the seventh or 128 possible pattern, PSKL proposes to transmit a 16 
bit frame for each character instead of ten. Here is where things differ 
from anything normal. 128 characters have to be selected. Finally Bill 


DeCarle came up with 128 codewords that differ from each other by at 
least six bit positions!! After all this is done then the computer 
selects the one character that has the smallest number of altered bits. 

Now before I scare everyone off with all this, realize that the work 
done so far is ORDINARY ASCII----just as you are using. The PSKL is 
simply something we are doing for future evaluation. 

Maybe now it becomes more apparent why I have no patience fooling 
around with a silly bulletin board system that will not work for me!! 
Cliff Buttschardt W6HDO 


From karn@qualcomm.com Mon Feb 12 17:42:32 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.3/8.7.3/1.8) with ESMTP id RAAQ9101 for <hfsig@tapr.org>; Mon, 12 Feb 1996 
17:42:29 -0600 (CST) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.3/8.7.2/1.4) id 
PAA17640; Mon, 12 Feb 1996 15:41:57 -@800 (PST) 

Date: Mon, 12 Feb 1996 15:41:57 -0800 (PST) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199602122341.PAA17640@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199602120509.HAA14738@£15.pix.za> (danie.brynard@pixie.co.za) 
Subject: Re: [HFSIG:869] Re: DSP Tools 


>Sounds exciting Phil. What software is available so far for the satellites ? 


I haven't written anything yet. I'm working on a m-ary FSK scheme that's 
designed primarily for HF. Because it has pretty stringent frequency 
stability requirements, I doubt it will work well on satellite channels. 


Phil 


From FORRERJ@frl.orst.edu Mon Feb 12 18:07:00 1996 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
tapr.org (8.7.3/8.7.3/1.8) with SMTP id SAA10285 for <HFSIG@TAPR.ORG>; Mon, 12 Feb 
1996 18:06:58 -0600 (CST) 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id QAA15003 for <HFSIG@TAPR.ORG>; Mon, 12 Feb 1996 
16:03:43 -0800 
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21); 
12 Feb 96 16:14:08 PST8PDT 
Received: from SpoolDir by FRL (Mercury 1.21); 12 Feb 96 16:13:41 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 
Date: Mon, 12 Feb 1996 16:13:32 -0800 
Subject: Thanks for help on EZKITAPP 
Priority: normal 
X-mailer: Pegasus Mail v3.22 
Message-ID: <25680386673@frl.orst.edu> 


Hi, 


Thanks for all the help with obtaining a good copy of the EZKITLITE 


file. Marv was kind enough to help me out. 
73's 
--Johan, KC7WW 


From sadowskp@jcsar.nellis.a£.mil Mon Feb 12 19:47:14 1996 

Received: from bncc.nellis.af.mil (bncc.nellis.af.mil [132.58.120.19]) by tapr.org 

(8.7.3/8.7.3/1.8) with SMTP id TAA13906 for <hfsig@tapr.org>; Mon, 12 Feb 1996 

19:47:11 -0600 (CST) 

Received: from mailgtwy.nellis.af.mil by bncc.nellis.af.mil with SMTP 
(1.38.193.4/16.2) id AA27742; Mon, 12 Feb 1996 17:40:00 -0800 

Received: by mailgtwy.nellis.af.mil with Microsoft Mail 
id <311FCF59@mailgtwy.nellis.af.mil>; Mon, 12 Feb 96 17:38:01 cst 

From: "Sadowski,P 04 USAF JCSAR/EDD" <sadowskp@jcsar.nellis.af.mil> 

To: hfsig <hfsig@tapr.org> 

Subject: RE: [HFSIG:853] SLOW BPSK NEWS 

Date: Wed, 07 Feb 96 11:12:00 cst 

Message-Id: <311FCF59@mailgtwy.nellis.af£.mil> 

Encoding: 60 TEXT 

X-Mailer: Microsoft Mail V3.0 


CONGRATS Pawel and Johan... keep up the good work... especially the 
FEC to make it more error free.... 


BTW... I understand the DSP eval board you are using has been upgraded 
by Motorola to a faster version 50MHz to 8QMHz... any impact??? 


ALOHA 

AL AH6LS 

From: hfsig 

To: hfsig 

Subject: [HFSIG:853] SLOW BPSK NEWS 

Date: Wednesday, February 07, 1996 11:50AM 


Hi all, 
Some exciting news that we want to share. 


Pawel, SP9VRC is presently at CERN, Switzerland, and have been patiently 
listening for my (KC7WW, Monroe, Oregon) slow speed BPSK transmissions on 
20 meters. My setup consists of a DSP56002EVM running Pawel's SLOWBPSK 
program, an an ICOM 751 on LSB mode, RF output is 10W to a Butternut 
vertical. 


For the first time; yesterday looked like Pawel got something - not yet 
confirming callsigns, but that is only a matter of time. Here is what he 
e-mailed me: 


Well, this time something did work. Today at 16:20 UTC I got a long lock 


(I didn't need to wait long for it) and then in the garbage characters 
I could clearly see CQ (with capital letters) being sent at least four 
times. 

They were not in a row but at a distance of some 60-80 characters. 

I could see as well the space before or after them. 


I was listenning with the TS-440 and I used the narrow filter 

(I didn't try the wide filter at that time). I was not able to 

hear any audible signal by ear. 

However, I noticed there is some weak but regular CW being sent on this 
or close frequency - it that you ? 


I left the setup running and the output is being recorded on a file. 
I will send you the file later. 

I have made a schedule at 20:00 UTC on 14.180 USB voice with Danie 
every day this week and weekend. 


I'm sure I would capture more text if we had the FEC and good block-sync. 
With asynchronous transmition one fake bit can spoil several 
characters... 


Pawel 


Sounds like fun, does'nt it ? 


--Johan, KC7WW 


From forrerj@ucs.orst.edu Tue Feb 13 01:41:07 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.3/8.7.3/1.8) with SMTP id BAAQ4816 for <hfsig@tapr.org>; Tue, 13 Feb 1996 
01:41:05 -0600 (CST) 
Received: from p06.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/24Sep94-1201PM) 
id AA29098; Mon, 12 Feb 1996 23:40:56 -0800 
Message-Id: <9602130740.AA29098@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Mon, 12 Feb 1996 23:44:58 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:879] RE: SLOW BPSK NEWS 


Hi Al, 
> 
>CONGRATS Pawel and Johan... keep up the good work... especially the 


>FEC to make it more error free.... 


Well, we are not sure that we actually made contact. We will know for sure 


one day when we see the callsigns in print. Anyway we are still trying. 


Yes - FEC could make the difference. A good sync vector is probably needed 
as well, and with the low signals, probably a lower the symbol rate as well. 
But its a good start. 


> 
>BTW... I understand the DSP eval board you are using has been upgraded 
>by Motorola to a faster version 50MHz to 80MHz... any impact??? 


I have gotten one of the new 66 MHz units - actually it is now the standard. 
It appears to run at 80 MHz, at least the programs I tried seem to run with 
no apparent problems. This is the unit that is running the beacon test - 
appears to be quite stable. 


--Johan 


From JALOCHA@vxcern.cern.ch Tue Feb 13 04:33:37 1996 

Received: from vscrna.cern.ch (vscrna.cern.ch [137.138.28.123]) by tapr.org 
(8.7.3/8.7.3/1.8) with SMTP id EAA10212 for <hfsig@tapr.org>; Tue, 13 Feb 1996 
04:33:35 -0600 (CST) 

Date: Tue, 13 Feb 1996 11:32:43 +0100 (CET) 

From: Pawel Jalocha <JALOCHA@vxcern.cern.ch> 

To: hfsig@tapr.org 

Message-Id: <960213113243 .21b2422c@vxcern.cern.ch> 

Subject: SLOWBPSK data format 


Hello to all, 


The SLOWBPSK.ASM makes an audio signal at 1650 Hz (defineable) which is 
DBPSK modulated at 31.25 bits/sec. The 31.25 comes from the 8000 Hz 
sampling which I divide by 256. 


Bit format: phase transition => logical 1 
no phase transition => logical 0 


Data encoding: asynchronous-like 7-bit ASCII: 
start-bit + seven data bits + stop bit. 
But note that the bit stream is still synchronous ! 


The receiver when not locked slowly sweeps a defineable audio range 
(like 1600-1700 Hz at 3 Hz/sec) and when locked it stops sweeping 
and decodes the data while still tracking the carrier. 


Obviously I am thinking of adding a FEC... my major problem 
is how to organize the blocks and how to synchronize to these 
at the receiver. 


Pawel 


From chbrain@dircon.co.uk Tue Feb 13 12:53:14 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 


tapr.org (8.7.3/8.7.3/1.8) with SMTP id MAA26640 for <hfsig@tapr.org>; Tue, 13 Feb 
1996 12:53:04 -0600 (CST) 
Received: by felix.dircon.co.uk id AA19557 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Tue, 13 Feb 1996 18:52:40 GMT 
Message-Id: <199602131852.AA19557@felix.dircon.co.uk> 
Received: from gw2-101.pool.dircon.co.uk(194.112.35.101) by amnesiac via smap 
(V1.3) 
id sma019526; Tue Feb 13 18:52:08 1996 
X-Sender: chbrain@popmail.dircon.co.uk 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Tue, 13 Feb 1996 18:22:59 +0000 
To: hfsig@tapr.org 
From: chbrain@dircon.co.uk (Charles Brain) 
Subject: Re: 56002 EVM 


Hello Johan, 

>I have gotten one of the new 66 MHz units - actually it is now the standard. 
>It appears to run at 80 MHz, at least the programs I tried seem to run with 
>no apparent problems. This is the unit that is running the beacon test - 
>appears to be quite stable. 

> 

>--Johan 

> 

> 

Do you have the part number for the EVM board. Is the 56002 a superset 

of the 56000 ? 


73 Charles G4GUO 


From forrerj@ucs.orst.edu Tue Feb 13 15:04:19 1996 
Received: from ucs.orst.edu (forrerj@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.3/8.7.3/1.8) with SMTP id PAAQ2043 for <hfsig@tapr.org>; Tue, 13 Feb 1996 
15:04:16 -0600 (CST) 
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM) 
id AA18768; Tue, 13 Feb 1996 13:04:05 -0800 
Date: Tue, 13 Feb 1996 13:04:04 -0800 (PST) 
From: Johan Forrer <forrerj@ucs.orst.edu> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:882] Re: 56002 EVM 
In-Reply-To: <199602131852.AA19557@felix.dircon.co.uk> 
Message-Id: <Pine.OSF.3.91.960213125531.6810A-100000@ucs.orst.edu> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi Charles, 


I don't want to sound like a Moto salesman - just my personal experiences 
for what it's worth. 


On Tue, 13 Feb 1996, Charles Brain wrote: 


Hello Johan, 

>I have gotten one of the new 66 MHz units - actually it is now the standard. 
>It appears to run at 80 MHz, at least the programs I tried seem to run with 
>no apparent problems. This is the unit that is running the beacon test - 
>appears to be quite stable. 

> 

>--Johan 

> 

> 

Do you have the part number for the EVM board. Is the 56002 a superset 

of the 56000 ? 


73 Charles G4GUO 


VV VV VV VV VV VV VV WV 


The part is still called the DSP56002EVM, but be sure to ask to make 
sure that the DSP has the "66" stamped on it. That is how you would know. 


The 56002 is part of the 56000 family and there are many similarities 
shared by products in the family. The 56002 uses a different die 

than the 56001, the new process giving it the higher clocking capability. 
I would not call it a "Superset" instruction set, but rather a few extra 
bits in some of the special registers that used to be labelled "reserved". 


Does this help? 
--Johan 


From s5éa@s55tcp.ampr.org Tue Feb 13 15:42:19 1996 

Received: from s55tcp.ampr.org (radio.kud-fp.si [193.2.132.80]) by tapr.org 

(8.7.3/8.7.3/1.8) with SMTP id PAAQ3290 for <hfsig@tapr.org>; Tue, 13 Feb 1996 

15:42:16 -0600 (CST) 

Date: Tue, 13 Feb 96 21:38:15 EST 

Message-Id: <139129@s55tcp.ampr.org> 

From: Marijan Miletic <s56a@s55tcp.ampr.org> 

Reply-To: S56A@s55tcp.ampr.org 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:882] Re: 56002 EVM 

In-Reply-To: your message of Tue Feb 13 12:55:46 1996 
<199602131852.AA19557@felix.dircon.co.uk> 


From chbrain@dircon.co.uk Tue Feb 13 15:52:43 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
tapr.org (8.7.3/8.7.3/1.8) with SMTP id PAAQ3934 for <hfsig@tapr.org>; Tue, 13 Feb 
1996 15:52:09 -0600 (CST) 
Received: by felix.dircon.co.uk id AAQ0Q748 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Tue, 13 Feb 1996 21:51:49 GMT 

Message-Id: <199602132151.AA00748@felix.dircon.co.uk> 
Received: from gw2-147.pool.dircon.co.uk(194.112.35.147) by amnesiac via smap 
(V1.3) 

id sma000733; Tue Feb 13 21:51:23 1996 
X-Sender: chbrain@popmail.dircon.co.uk 


X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 
Date: Tue, 13 Feb 1996 21:22:18 +0000 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 
Subject: Re: [HFSIG:883] Re: 56002 EVM 


> 

>The part is still called the DSP56002EVM, but be sure to ask to make 
>sure that the DSP has the "66" stamped on it. That is how you would know. 
> AN 

Hi Johan, 

Yes that helps, Its difficult to explain to people at the other end of the 
phone the differences in these things. 


I guess I'll get one of these as it seems to be the platform of choice for 
HFSIG, better than the TI DSK. I only asked about the superset !? as I 
have a 56000 assembler manual upstairs so I can look at that. 


Tnx again 
Charles G4GUO 


From FORRERJ@frl.orst.edu Wed Feb 14 11:26:50 1996 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
tapr.org (8.7.3/8.7.3/1.8) with SMTP id LAA21924 for <hfsig@tapr.org>; Wed, 14 Feb 
1996 11:26:47 -0600 (CST) 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id JAA22410 for <hfsig@tapr.org>; Wed, 14 Feb 1996 
09:23:25 -0800 
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21); 
14 Feb 96 09:33:54 PST8PDT 
Received: from SpoolDir by FRL (Mercury 1.21); 14 Feb 96 09:33:29 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Wed, 14 Feb 1996 09:33:23 -0800 
Subject: New EVM library available 
Priority: normal 
X-mailer: Pegasus Mail v3.22 
Message-ID: <27FD5DB54C8@frl.orst.edu> 


Hi, 

I have updated the DSP56002EVM software library with the more recent 
versions of code. It is now available for downloading as 
EVM56K2A.TXT and EVM56K2A.ZIP from the tapr/SIG/hfsig/upload area. 


As usual, this is the full source code to everything that was contributed. 


Thank you to those that generously contributed their fine efforts - we 
are most appreciative. 


Enjoy. 
--Johan, KC7WW 


From FORRERIJ@frl.orst.edu Wed Feb 14 16:00:11 1996 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
tapr.org (8.7.3/8.7.3/1.8) with SMTP id QAAQ2810 for <HFSIG@TAPR.ORG>; Wed, 14 Feb 
1996 16:00:08 -0600 (CST) 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id NAA23691 for <HFSIG@TAPR.ORG>; Wed, 14 Feb 1996 
13:56:45 -0800 
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21); 
14 Feb 96 14:07:14 PST8PDT 
Received: from SpoolDir by FRL (Mercury 1.21); 14 Feb 96 14:07:07 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 
Date: Wed, 14 Feb 1996 14:06:58 -0800 
Subject: Sync Vectors for HF Digital 
Priority: normal 
X-mailer: Pegasus Mail v3.22 
Message-ID: <28465840951@frl.orst.edu> 


Hi all, 


I am looking for ideas on a suitable sync. vector for use on HF, 
something better than what is currently used on Packet or Pactor for 
instance. 


In this regard, AX.25 Packet use "7Eh", Pactor uses a "55h/AAh" 
pattern, the so-called "header byte." BTW not really for frame sync 
purposes - that is done by brute force search for a valid CRC over a 
block of raw bits. 


Phil suggests a 63-bit PN sequence in his "Toward New Link Layer Protocols" 
where a 13/64 match is considered a hit. That is some 8 bytes long - is 
this the kind of header that should be used. 


Any suggestions or ideas would be welcome. 
Thanks in advance. 
--Johan, KC7WW 


From chbrain@dircon.co.uk Thu Feb 15 04:14:01 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
tapr.org (8.7.3/8.7.3/1.8) with SMTP id EAAQ5297 for <hfsig@tapr.org>; Thu, 15 Feb 
1996 04:13:55 -0600 (CST) 
Received: by felix.dircon.co.uk id AA01304 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 15 Feb 1996 10:12:47 GMT 
Message-Id: <199602151012 .AA01304@felix.dircon.co.uk> 
Received: from gw2-132.pool.dircon.co.uk(194.112.35.132) by amnesiac via smap 


(V1.3) 
id sma005951; Thu Feb 15 07:51:53 1996 
X-Sender: chbrain@popmail.dircon.co.uk 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Thu, 15 Feb 1996 07:22:27 +0000 
To: hfsig@tapr.org 
From: chbrain@dircon.co.uk (Charles Brain) 
Subject: Re: [HFSIG:887] Sync Vectors for HF Digital 


>Hi all, 

> 

>I am looking for ideas on a suitable sync. vector for use on HF, 
>something better than what is currently used on Packet or Pactor for 
>instance. 

> 

>--Johan, KC7WW 

> 

> 

Hello Johan, 

You could use Barker codes, the HF modem we have at work use them for 
sync. These codes are described on page 10-61 of "The ARRL Spread 
Spectrum Source Book". In fact appendix B of that book has a whole 
section on synch after clock recovery. 


73 Charles 


From k4gvo@america.net Thu Feb 15 04:42:08 1996 

Received: from america.net (atl1.america.net [199.170.121.2]) by tapr.org 
(8.7.3/8.7.3/1.8) with SMTP id EAAQ6195 for <hfsig@tapr.org>; Thu, 15 Feb 1996 
04:42:06 -0600 (CST) 

Message-Id: <199602151042.EAA06195@tapr.org> 

Received: from k4gvo (pm1-14.america.net [199.170.121.114]) by america.net 
(8.6.10/8.6.9) with SMTP id FAAQ9417 for <hfsig@tapr.org>; Thu, 15 Feb 1996 
05:45:05 -0500 

Sender: <k4gvo@atl1.america.net> 

From: "Jim Lynch" <k4gvo@america.net> 

To: hfsig@tapr.org 

Date: Thu, 15 Feb 1996 05:40:49 +0000 

Subject: Re: [HFSIG:887] Sync Vectors for HF Digital 

Reply-to: k4gvo@america.net 

Priority: normal 

X-mailer: Pegasus Mail/Windows (v1.22) 


> Date: Wed, 14 Feb 1996 16:17:59 -0600 (CST) 

> Reply-to: hfsig@tapr.org 

> From: "Johan Forrer" <FORRERJ@frl.orst.edu> 

> To: hfsig@tapr.org 

> Subject: [HFSIG:887] Sync Vectors for HF Digital 
> Hi all, 


> I am looking for ideas on a suitable sync. vector for use on HF, 

> something better than what is currently used on Packet or Pactor for 

> instance. 

> 

> In this regard, AX.25 Packet use "7Eh", Pactor uses a "55h/AAh" 

> pattern, the so-called "header byte." BTW not really for frame sync 

> purposes - that is done by brute force search for a valid CRC over a 

> block of raw bits. 

> 

> Phil suggests a 63-bit PN sequence in his "Toward New Link Layer Protocols" 
> where a 13/64 match is considered a hit. That is some 8 bytes long - is 
> this the kind of header that should be used. 

> 

> Any suggestions or ideas would be welcome. 

> 

> Thanks in advance. 

> 

> --Johan, KC7WW 

Hi, Johan. 


Would it make sense to have the header adaptive? I like Phil's idea, 
but it might be a waste of time for very good connections. How about 
a one byte header for great connections, no retries, a 4 byte header 
for fair connections and an_ 8 byte for the I-don't-hear-anyone 
connections. 


Jim. 

> 

> 

Jim Lynch Fayetteville, GA K4GVO 

‘86 GL1200I k4gvo@america.net 44 .36.34.20 


From dona@tridelta.com Thu Feb 15 07:43:32 1996 

Received: from wariat.wariat.org (uucp@wariat.wariat.org [192.147.147.1]) by 
tapr.org (8.7.3/8.7.3/1.8) with ESMTP id HAA11371 for <hfsig@tapr.org>; Thu, 15 
Feb 1996 07:43:29 -Q600 (CST) 

Received: from tridelta.com (uucp@localhost) by wariat.wariat.org (8.6.12/8.6.9) 
with UUCP id IAA21378 for hfsig@tapr.org; Thu, 15 Feb 1996 08:43:22 -0500 
Received: from sparcy.tridelta.com (sparcy [192.160.168.222]) by tdi3.tridelta.com 
(8.6.9/8.6.9) with ESMTP id IAAQ7193 for <hfsig@tapr.org>; Thu, 15 Feb 1996 
08:36:16 -0500 

Received: from donapc.tridelta.com (donapc.tridelta.com [192.160.168.70]) by 
sparcy.tridelta.com (8.7.1/8.7.1) with SMTP id IAA28704 for <hfsig@tapr.org>; Thu, 
15 Feb 1996 08:35:28 -0500 (EST) 

Date: Thu, 15 Feb 1996 08:35:28 -0500 (EST) 

Message-Id: <199602151335.IAA28704@sparcy.tridelta. com> 

X-Sender: dona@sparcy 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: dona@tridelta.com (Don Adams) 

Subject: Re: [HFSIG:889] Re: Sync Vectors for HF Digital 


> 

>Would it make sense to have the header adaptive? I like Phil's idea, 

>but it might be a waste of time for very good connections. How about 

>a one byte header for great connections, no retries, a 4 byte header 

>for fair connections and an 8 byte for the I-don't-hear-anyone 
>connections. 

> 

>Jim. 

>> 

>> 

>Jim Lynch Fayetteville, GA K4GV0O 

>'86 GL1200I k4gvo@america.net 44.36.34.20 

> 

> 

In the old IBM bisync world, the sync was esablished as the first non sync 
character 

afer a string >1 sync characacters. This idea is simple and would allow U to 
integrate (corrolate) over many (8 or 4 or what ever) when establishing the 
contact 

and then shorten it as need be for appropiate signal quality. The sync 
char, itself, 

(I think it was a control V or there abouts), had good corrolation qualities 
of its own. 


From forrerj@ucs.orst.edu Thu Feb 15 11:06:59 1996 
Received: from ucs.orst.edu (forrerj@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.3/8.7.3/1.8) with SMTP id LAA19372 for <hfsig@tapr.org>; Thu, 15 Feb 1996 
11:06:52 -0600 (CST) 
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM) 
id AA25065; Thu, 15 Feb 1996 09:06:46 -0800 
Date: Thu, 15 Feb 1996 09:06:46 -0800 (PST) 
From: Johan Forrer <forrerj@ucs.orst.edu> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:888] Re: Sync Vectors for HF Digital 
In-Reply-To: <199602151012.AA01304@felix.dircon.co.uk> 
Message-Id: <Pine.OSF.3.91.960215085929 .31390C -100000@ucs.orst.edu> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Charles, 


On Thu, 15 Feb 1996, Charles Brain wrote: 


Hello Johan, 

You could use Barker codes, the HF modem we have at work use them for 
sync. These codes are described on page 10-61 of "The ARRL Spread 
Spectrum Source Book". In fact appendix B of that book has a whole 
section on synch after clock recovery. 


VV VV VV WV 


73 Charles 


I 


have been meaning to buy that book - this weekend at the swap I'll get 


it. Thanks for the pointer. 


Last night I did a bit of reading up and see the Barker sequence has very 
good properties. The main issue is the autocorrelation function that give 


a 


high only at the perfect sync position and next to nil when offset by 


any other amount. The book also stated that the right PN sequence may be 
as good as a Barker sequence in many situations. The maximum length 
known Barker sequence is only 13 bits long. 


Thanks to Kok Chen that also pointed this out. 


--Johan 


From frode@dxcern.cern.ch Fri Feb 16 05:32:57 1996 

Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by tapr.org 
(8.7.3/8.7.3/1.8) with SMTP id FAAQ6579 for <hfsig@tapr.org>; Fri, 16 Feb 1996 
05:32:44 -0600 (CST) 

Received: from dxcern.cern.ch by dxmint.cern.ch 


id AA15143; Fri, 16 Feb 1996 12:32:08 +0100 


Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 


id AA29684; Fri, 16 Feb 1996 12:32:07 +0100 


Date: Fri, 16 Feb 1996 12:32:06 +0100 (MET) 
From: Frode Weierud <frode@dxcern.cern.ch> 


To: 


hfsig@tapr.org 


Subject: Re: [HFSIG:891] Re: Sync Vectors for HF Digital 

In-Reply-To: <Pine.OSF.3.91.960215085929 .31390C-100000@ucs.orst.edu> 
Message-Id: <Pine.ULT.3.91.960216121418 .29122A-100000@dxcern.cexrn.ch> 
Mime-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Thu, 15 Feb 1996, Johan Forrer wrote: 


VVVVVV VV WV 


I 


Last night I did a bit of reading up and see the Barker sequence has very 
good properties. The main issue is the autocorrelation function that give 
a high only at the perfect sync position and next to nil when offset by 
any other amount. The book also stated that the right PN sequence may be 
as good as a Barker sequence in many situations. The maximum length 

known Barker sequence is only 13 bits long. 


Thanks to Kok Chen that also pointed this out. 


have promised to give Johan some references on synchronisation that I 


have recently been looking at. As I suppose others might be interested as 
well, I will post them here. 


There are specially three references dealing with Code-assisted bit 
synchronisation (CABS) that combine synchronisation and error-correction 
coding. 


P. Couton, C. Hannaford and B. Honary, "Coding for both protection and 
synchronisation", IEE Proc. Commun. Vol. 142, No.6, Dec. 1995, pp.352-356. 


This is a more general paper on the use of CABS with other waveforms than 
MFSK, which is the subject of the next two papers. 


B. Honary, F. Zolghadr and M. Darnell, "Code-assisted bit synchronisation 
(CABS) scheme", Electronic Letters, vol.25, No.2, pp.152-153. 


B. Honary, F. Zolghadr, M. Darnell and M. Maundrell, "Improved HF modem 
using convolutional coding", Electronics & Communication Engineering 
Journal, Vol.4, No.2, April 1992, pp.73-82. 


Concerning Barker sequences and word synchronisation generally the next 
paper has a very good analysis. 


M. Grayson and M. Darnell, "Extended analysis of word synchronisation 
using sequence correlation techniques", IEE Proc. Commun. Vol. 142, No.6, 
Dec. 1995, pp.357-362. 


Johan was earlier asking for references on punctured codes. I know I have 
some other references somewhere, but here is at least one that I have 
briefly had a look at last year. 


Jack Keil Wolf and Ephraim Zehavi, "P*2 Codes: Pragmatic Trellis Codes 
Utilizing Punctured Convolutional Codes", IEEE Communication Magazine, 
Feb. 1995, pp.94-99. 


Have an enjoyable read, :-) 
73's Frode 
Frode Weierud Phone : 41 22 7674794 
CERN, SL Fax : 41 22 7679185 
CH-1211 Geneva 23, Switzerland E-mail : frode@dxcern.cern.ch 


From forrerj@ucs.orst.edu Fri Feb 16 11:49:36 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.3/8.7.3/1.8) with SMTP id LAA19899 for <hfsig@tapr.org>; Fri, 16 Feb 1996 
11:49:32 -0600 (CST) 
Received: from p07.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/24Sep94-1201PM) 
id AA11073; Fri, 16 Feb 1996 09:48:59 -0800 
Message-Id: <9602161748 .AA11073@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Fri, 16 Feb 1996 09:53:56 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:892] Re: Sync Vectors for HF Digital 


Dear Frode, 


Thank you for the references. I have seen some of those and they are quite 
interesting. 


>I have promised to give Johan some references on synchronisation that I 
>have recently been looking at. As I suppose others might be interested as 
>well, I will post them here. 

> 

>There are specially three references dealing with Code-assisted bit 
>synchronisation (CABS) that combine synchronisation and error-correction 
>coding. 

> 


As you might have guessed - I am in the process of putting together some 
rudimentary definition for use as a data link layer. I like Phil's general 
proposal in this regard with a few provisions to make it work on HF. I then 
propose to define it as: 


1) Hybrid type II ARQ. - frame/cycle time timing fixed. 
More on the Hybrid ARQ later. 

2) Convolutional code with constraint length 7. 

3) Fixed symbol rate - data rate variable by use of punctured 
code in addition to data compression. 


It appears that there are some choices for the frame sync sequence. The 
13-bit Barker sequence looks like a good choice - unless someone has a good 
argument against it. Detecting the sequence or deriving bit timing, is where 
CABS may be used with additional advantage as it is Viterbi decoder. 
Experience has taught us, however, that bit sync for HF data must be a 
dynamic process that is applied throughout the bit stream and one cannot 
rely only on timing achieved at the sync vector. The sole purpose of the 
sync vector is to find the beginning of the frame. This is particularly 
valid when dealing with frames of any significant time duration. 


The next question is then: 


What should one use for the reverse channel signaling, i.e., the ACK's and 
NAK's etc. 

I understand that longish (12 bits for example) PN sequences works 
reasonably well. 


For those that are not familiar with what these are used for - when the 
sending station sends a data frame, the receiver need to signal back that it 
decoded the previous frame correctly and awaits the next frame. Or if it 
decoded an error, in the type II scheme, the sender will send some more 
coding bits, not the whole frame - this will help the receiver to "patch up 
the frame" using error-correction techniques (the incentive being that much 
shortened frames are sent, and thus increased throughput results). A problem 
exsists, however, when the sending station fails to read the ACK/NACK 
(perhaps due to interference or fading, or it is garbled.) One can see that 
a "weak" system of ACK/NACK's , also called the "reverse channel", will tend 


to give low throughput or even disastrous link failure when conditions are 
marginal. Designing strong reverse channel signalling is as important as the 
forward channel coding. 


OK, with that out of the way - with the similar arguments as for the sync 
vector selection, PN sequences have been proven to be very powerful for use 
in reverse channel signaling. Keep in mind that the actual ACK/NACK 
*CHANGES* with every frame (of course the sender and receiver uses the same 
PN generator algorithm so they know what to expect). The question is whether 
there is something better and how long a sequence do we need?? 


Any suggestions/critisism/ideas on the proposed scheme are welcome. 
Thanks, 


--Johan, KC7WW 


From chbrain@dircon.co.uk Sat Feb 17 01:52:49 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
tapr.org (8.7.3/8.7.3/1.8) with SMTP id BAAQ2598 for <hfsig@tapr.org>; Sat, 17 Feb 
1996 01:52:47 -0600 (CST) 
Received: from nameserver.dircon.co.uk (gw2-107.pool.dircon.co.uk) by 
felix.dircon.co.uk with SMTP id AA23485 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 17 Feb 1996 07:52:38 GMT 
Message-Id: <199602170752.AA23485@felix.dircon.co.uk> 
X-Sender: chbrain@popmail.dircon.co.uk 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Sat, 17 Feb 1996 07:22:50 +0000 
To: hfsig@tapr.org 
From: chbrain@dircon.co.uk (Charles Brain) 
Subject: Re: [HFSIG:893] Re: Sync Vectors for HF Digital 


Hello Johan, 
>a "weak" system of ACK/NACK's , also called the "reverse channel", will 
>--Johan, KC7WW 


Another idea to throw into the melting pot, if you send a data block and 
hear no ACK/NAK i.e you timeout, should you send the data block again 

or simply request the last ACK/NAK to be resent ? I tried this on a simple 
H.F protocol a while back, this protocol had a window of one and it did seem 
to improve things especially as the transmitted data blocks were very long, 
(I was using very deep interleaving) and took a long time to resend. 


I guess if the data blocks are short there is no need to do this. 
Regards Charles G4GUO 


From FORRERJ@frl.orst.edu Mon Feb 19 13:20:13 1996 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 


tapr.org (8.7.3/8.7.3/1.8) with SMTP id NAA20906 for <HFSIG@TAPR.ORG>; Mon, 19 Feb 
1996 13:20:10 -0600 (CST) 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id LAA11406 for <HFSIG@TAPR.ORG>; Mon, 19 Feb 1996 
11:16:27 -0800 
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21); 
19 Feb 96 11:27:09 PST8PDT 
Received: from SpoolDir by FRL (Mercury 1.21); 19 Feb 96 11:26:51 PST8PDT 
From: "Johan Forrer" <FORRERJ@fr1l.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 
Date: Mon, 19 Feb 1996 11:26:51 -0800 
Subject: More BPSK news 
Priority: normal 
X-mailer: Pegasus Mail v3.22 
Message-ID: <2F9BD135FO09@frl.orst.edu> 


Hi all, 
Some more news on BPSK experiments on HF. 


Contact was made on 10.137 between Paul, PAOOCD and Timo, OH2LVZ on Sunday 
February 19th using the SP9VRC program. Congratulations! 


Copy was about 80% with signals being weak and in the noise. I believe 
that signals was inaudible most of the time. Paul was using the 56002EVM 
and Timo the DSP4. 


It is evident that the trick is how to find the correct frequency. The 
software will track slight off-frequency operation, however, good frequency 
resolution is needed on the tranceivers. Paul suggested that a good 
realtime FFT analyser program is good for this purpose. When used in 
persistance/integrate mode, these weak signals can clearly be seen. 


Keep in mind that no error-correcting coding is used at the present time, 
its a good demodulator and the relatively long symbol times that does it. I 
think Pawel is ready to play with some ECC next? 


I also have been hearing from Cliff, W6HDO, that he hears my beacon in the 
early mornings. If there is anyone here in the US interested in BPSK 

or high speed OFDM, please let me know so we can arrange for a sked time 
and frequency. 


Congratulations again and keep up the good work. 


--Johan, KC7WW 


From FORRERJ@frl.orst.edu Wed Feb 21 11:59:41 1996 

Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
tapr.org (8.7.3/8.7.3/1.8) with SMTP id LAAQ4487 for <HFSIG@TAPR.ORG>; Wed, 21 Feb 
1996 11:59:34 -0600 (CST) 

Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu 


(8.6.9/8.6.9) with ESMTP id JAA19252 for <HFSIG@TAPR.ORG>; Wed, 21 Feb 1996 
09:55:45 -0800 
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21); 
21 Feb 96 10:06:29 PST8PDT 
Received: from SpoolDir by FRL (Mercury 1.21); 21 Feb 96 10:06:28 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 
Date: Wed, 21 Feb 1996 10:06:25 -0800 
Subject: QST tidbits 
Priority: normal 
X-mailer: Pegasus Mail v3.22 
Message-ID: <328676C1A2D@fr1l.orst.edu> 


Hi all, 
Wonder if you had a chance to look at the latest issue of QST yet? 


It contains an interesting article by Grant Zehr on using JVFAX 7.1. 

The article includes the description of an analog APT convertor as well. 
You might be interested to know that this same functionality and a lot more 
is offered by using Pawel's FSKIFACE program for the 56K EVM. For example, 
you also get full transmit capability for WEFAX and SSTV, if that may be 

of interest to you. The FSKIFACE program for the EVM is included in the 
latest EVM software package on the HFSIG upload area. 


The other tidbit that came as a surprize. Looking closely at the 
advertisement of AEA's latest DSP box, I noticed that the DSP used in 
that product is an Analog Devices 2105 DSP. The baoard also contains a 
Motorola 68K family microcontroller. This arrangement appears to offer 
potential for all sorts of future applications. 


HAL also shows their new stand-alone Clover unit. Instead of the usual PC- 
plugin card, the unit is self-contained. I am not sure whether this 

one uses the older 56001 design or the 320C25 design as used in the P38. 
Someone may wish to comment on that. 


MFJ have been offereing a DSP option for some of their HF all- 
mode units, though it appears to me as if it is some kind of pre-filtexr DSP 


arrangement instead of a DSP modem. 


It certainly look like DSP is making it into a lot of amateur radio gear 
these days. 


73's 


--Johan, KC7WW 


--Johan 


From frode@dxcern.cern.ch Thu Feb 22 04:10:05 1996 
Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by tapr.org 
(8.7.3/8.7.3/1.8) with SMTP id EAA20909 for <hfsig@tapr.org>; Thu, 22 Feb 1996 
04:10:03 -0600 (CST) 
Received: from dxcern.cern.ch by dxmint.cern.ch 
id AAQQ726; Thu, 22 Feb 1996 11:09:30 +0100 
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AAQ3034; Thu, 22 Feb 1996 11:09:30 +0100 
Date: Thu, 22 Feb 1996 11:09:29 +0100 (MET) 
From: Frode Weierud <frode@dxcern.cern.ch> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:896] QST tidbits 
In-Reply-To: <328676C1A2D@frl.orst.edu> 
Message-Id: <Pine.ULT.3.91.960222095839 .29501A-100000@dxcern.cern.ch> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Wed, 21 Feb 1996, Johan Forrer wrote: 


The other tidbit that came as a surprize. Looking closely at the 
advertisement of AEA's latest DSP box, I noticed that the DSP used in 
that product is an Analog Devices 2105 DSP. The baoard also contains a 
Motorola 68K family microcontroller. This arrangement appears to offer 
potential for all sorts of future applications. 


VV VV Vv 


To see the technical details of the DSP232 have a look at AEA's home page 
URL: http://www.mvangel.com/aea/ 


Frode 
Frode Weierud Phone : 41 22 7674794 
CERN, SL Fax : 41 22 7679185 
CH-1211 Geneva 23, Switzerland E-mail : frode@dxcern.cern.ch 


From 72253.2602@compuserve.com Thu Feb 22 05:36:55 1996 
Received: from arl-img-6.compuserve.com (arl-img-6.compuserve.com [198.4.7.6]) by 
tapr.org (8.7.3/8.7.3/1.8) with SMTP id FAA23442 for <hfsig@tapr.org>; Thu, 22 Feb 
1996 05:36:54 -0600 (CST) 
Received: by arl-img-6.compuserve.com (8.6.10/5.950515) 

id GAAQ1799; Thu, 22 Feb 1996 06:36:38 -0500 


Date: 22 Feb 96 06:35:30 EST 

From: Peter Schulze <72253.2602@compuserve.com> 

To: HFSIG <hfsig@tapr.org> 

Subject: Re: DSP4100 

Message-ID: <960222113530_72253 .2602_EHJ48-5@CompuServe. COM> 


The DSP4100 is using a design similar to the 4000 boards with the 56000 as DSP. 
The 68000 now is a 12Mhz version. Large FlashRoms keep all the code. 
Ram size has been extended too and the long sockets are there for even larger Ram 


chips. 
They need the power to run their new 2khz clover on the units. 


Please see my complete review of the unit in the February issue of the 
digital journal (http://www.iea.com/~adrs) for more details. 


73 
Peter TY1PS 


mR a KK a KK KK KK KEK 
EURAF / DTS 

B.P. 06-2535, Cotonou, BENIN 

Tel.: +229-313779 

Fax : +229-313879 

72253 .2602@compuserve.com 

Latest DTS info on the WEB: 

http: //ourworld. compuserve.com/homepages/EURAF 

mR a a KK a KK RK KKK KEK 


From forrerj@ucs.orst.edu Thu Feb 22 12:05:43 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.3/8.7.3/1.8) with SMTP id MAAQ8816 for <hfsig@tapr.org>; Thu, 22 Feb 1996 
12:05:41 -0600 (CST) 
Received: from p06.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/24Sep94-1201PM) 
id AA27968; Thu, 22 Feb 1996 10:05:21 -0800 
Message-Id: <9602221805.AA27968@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Thu, 22 Feb 1996 10:11:04 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:894] Re: Sync Vectors for HF Digital 


Charles, 


>Hello Johan, 

>>a "weak" system of ACK/NACK's , also called the "reverse channel", will 
>>--Johan, KC7WW 

> 

>Another idea to throw into the melting pot, if you send a data block and 
>hear no ACK/NAK i.e you timeout, should you send the data block again 
>or simply request the last ACK/NAK to be resent ? 


This is a problem area when sending partial coded blocks. Here is how I see 
it: If the receiver read a block perfectly, and it's ACK reponse gets lost 
(times out as you say), we simply resend the last block. Although the 
receiving end expects the next block, it will see that the packet counter 
has not been incremented nor did the sync vector change and thus knows that 


it is a repeat. Only if the sender gets requested specifically to act upon a 
block received in error will it send another layer of coding bits. 


Does this make sense? 


>I tried this on a simple 

>H.F protocol a while back, this protocol had a window of one and it did seem 
>to improve things especially as the transmitted data blocks were very long, 
>(I was using very deep interleaving) and took a long time to resend. 

> 

>I guess if the data blocks are short there is no need to do this. 

> 

>Regards Charles G4GUO 

> 

> 


I do think this idea of shortened blocks, invertible codes, and punctured 
code for variable coding rate, should pay off in overall transmitting times. 
One thing though that one must guard against is a protocol that has too many 
default timeout counters - this is where things break down, i.e., when one 
gets in the middle of a speed change and for example, interference sets in 
during some crucial link status update stage. All it takes is one missed 
state and the PN sequences are out of step. 


Sounds like a lot of fun. 


--Johan 


From forrerj@ucs.orst.edu Thu Feb 22 12:30:13 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.3/8.7.3/1.8) with SMTP id MAAQ9519 for <hfsig@tapr.org>; Thu, 22 Feb 1996 
12:30:11 -0600 (CST) 
Received: from p09.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/24Sep94-1201PM) 
id AA22325; Thu, 22 Feb 1996 10:30:04 -0800 
Message-Id: <9602221830.AA22325@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu (Unverified) 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Thu, 22 Feb 1996 10:35:39 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:898] Re: DSP4100 


Hello Peter, 


Thanks for the pointer to your review article - I found it very informative. 
Good job! 


>The DSP4100 is using a design similar to the 4000 boards with the 56000 as DSP. 
>The 68000 now is a 12Mhz version. Large FlashRoms keep all the code. 


>Ram size has been extended too and the long sockets are there for even 
larger Ram chips. 
>They need the power to run their new 2khz clover on the units. 


I don't think this is a typo about the 2kHz Clover units - could you please 
expand a bit on what this is about. I thought HAL was pushing for 500 Hz 
bandwidth, but perhaps this is a new development? Four parallel Clover 
channels = 2 kHz bandwidth, at roughly 800 x 4 = 3200 bps. In my opinion, 
this is a welcome and needed step in the right direction. 


Judging from your description, I can see why a better 68K controller was 
needed. This is one aspect that is often overlooked - the DSP front-end 

hardware effort is minimal compared to what is involved in the protocol 

controller. 


Thanks for the contribution, Peter. 


> 

>Please see my complete review of the unit in the February issue of the 
>digital journal (http://www.iea.com/~adrs) for more details. 
> 

>73 

>Peter TY1PS 

> 

> 

DR RR RR RR KR KK OK 
>EURAF / DTS 

>B.P. 06-2535, Cotonou, BENIN 

>Tel.: +229-313779 

>Fax : +229-313879 

>72253 .2602@compuserve.com 

>Latest DTS info on the WEB: 

>http: //ourworld.compuserve.com/homepages/EURAF 

DR RR RR RR RR KK KK 

> 

> 


--Johan, KC7WW 


From chbrain@dircon.co.uk Thu Feb 22 15:33:11 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
tapr.org (8.7.4/8.7.3/1.8) with SMTP id PAA17669 for <hfsig@tapr.org>; Thu, 22 Feb 
1996 15:33:07 -0600 (CST) 
Received: from nameserver.dircon.co.uk (gw2-152.pool.dircon.co.uk) by 
felix.dircon.co.uk with SMTP id AA29500 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 22 Feb 1996 21:33:07 GMT 
Message-Id: <199602222133.AA29500@felix.dircon.co.uk> 
X-Sender: chbrain@popmail.dircon.co.uk 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 


Date: Thu, 22 Feb 1996 21:02:07 +0000 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 

Subject: Re: [HFSIG:899] Re: Sync Vectors for HF Digital 


>it is a repeat. Only if the sender gets requested specifically to act upon a 
>block received in error will it send another layer of coding bits. 

> 

>Does this make sense? 

> 

> 

Yep it makes sense, 


I think some (all!) of Phil's ideas are worth while. I think he has a 
postscript 
file on his www page describing them. 


A lot of the complexity I have seen in STANAG and MIL-STD protocols 
is to do with allowing pre-emption of traffic when higher priority stuff 
comes in, something we don't have to worry about?! 


I was reading a SHAPE report that came to the conclusion that adapting 
the modulation scheme was far more important than changing the data link 
parameters. Well that was the understanding I got from it! 


Regards Charles G4GUO. 


From frode@dxcern.cern.ch Fri Feb 23 09:34:50 1996 
Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by tapr.org 
(8.7.4/8.7.3/1.8) with SMTP id JAAQ2371 for <hfsig@tapr.org>; Fri, 23 Feb 1996 
09:34:47 -0600 (CST) 
Received: from dxcern.cern.ch by dxmint.cern.ch 
id AA11455; Fri, 23 Feb 1996 11:24:22 +0100 
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA26366; Fri, 23 Feb 1996 11:24:21 +0100 
Date: Fri, 23 Feb 1996 11:24:21 +0100 (MET) 
From: Frode Weierud <frode@dxcern.cern.ch> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:900] Re: DSP4100 
In-Reply-To: <9602221830.AA22325@ucs.orst.edu> 
Message-Id: <Pine.ULT.3.91.960223112226 .25523A-100000@dxcern.cexrn.ch> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Thu, 22 Feb 1996, Johan Forrer wrote: 


I don't think this is a typo about the 2kHz Clover units - could you please 
expand a bit on what this is about. I thought HAL was pushing for 500 Hz 
bandwidth, but perhaps this is a new development? Four parallel Clover 
channels = 2 kHz bandwidth, at roughly 800 x 4 = 3200 bps. In my opinion, 
this is a welcome and needed step in the right direction. 


VVVV VV 


Here is some info distributed on the WUN Mailing list: 


>From BrunoUSA@aol.comFri Feb 23 11:21:58 1996 

Date: Wed, 24 Jan 1996 00:05:05 -0500 

From: BrunoUSA@aol.com 

To: wun@grove.net 

Subject: [WUN] CLOVER-2000 (Q-CLOVER, Quad-CLOVER) listen-in ! 


If any of you are interested in "listening" to this new digital 
communications mode, tune your receivers to 11.0776 MHz or 10.3976 MHz, USB 
starting at 09h00 PST, Wednesday, January 24th. 


We will be experimenting the "beta" CLOVER-2000 (Q-CLOVER or Quad-CLOVER as 
it is also called) between our base in Escondido, California and a remote 
site in Illinois. 

CLOVER-2000 is similar to standard CLOVER except that it is 2KHz wide and is 
comprized of 8-tones (both phase & amplitude modulated)... it sounds quite 
different friom "regular" CLOVER. 

We are running 100 Watts PEP into a 16 element LPDA @ 65' in California. Our 
counterpart also has a LPDA... both are aimed at each other. 


This will give you an opportunity of "listening" to this new "sound"... by 
the way, if you monitor these frequencies, you will also hear other more 
exotic modes (39-tone, ALE, serial-tone, cypher, etc.) as they are part of 
our assigned HF test frequencies. 


If you hear us... drop me e-mail at: bhaineau@cts.com and I will confirm 
valid reports (describe the "sounds" you are hearing... and if you do manage 
to decode the traffic, you will earn extra brownie points ;-) 


Good listening... 


Bruno Haineault 


This is the WUN mailing list. 

To post to the list, send a e-mail to : wun@grove.net 

To unsubscribe the list, send a mail to: majordomo@grove.net 
with only "unsubscribe wun" in the BODY of the e-mail. 


73's Frode 
Frode Weierud Phone : 41 22 7674794 
CERN, SL Fax : 41 22 7679185 
CH-1211 Geneva 23, Switzerland E-mail : frode@dxcern.cern.ch 


From k5yfw@sacdm01.kelly.af.mil Fri Feb 23 13:15:41 1996 


Received: from sacdm01.kelly.af.mil ([137.242.64.1]) by tapr.org (8.7.4/8.7.3/1.8) 
with SMTP id NAA10477 for <hfsig@tapr.org>; Fri, 23 Feb 1996 13:11:39 -Q600 (CST) 
Received: by sacdm01.kelly.af.mil (5.65b/1.0.2-rct) 
id AA16763; Fri, 23 Feb 96 12:54:35 -0600 
Message-Id: <9602231854.AA16763@sacdm01.kelly.af£.mil> 
Date: Fri, 23 Feb 96 12:54:31 -0600 
From: k5yfw@sacdm01.kelly.af.mil (WALT DUBOSE - K5YFW) 
Subject: CLOVER 2000 (Q-CLOVER) 
To: bhaineau@cts.com 
Cc: hfsig@tapr.org 
X-Orig-Date: Fri, 23 Feb 1996 09:47:24 -Q600 (CST) 
X-Orig-From: Frode Weierud <frode@dxcern.cern.ch> 
X-Orig-Message-Id: <Pine.ULT.3.91.960223112226 .25523A-100000@dxcern.cern.ch> 


Bruno, 
_BRAVO_ 


I believe you are on the _right_ track now. A couple of years ago I 
corresponded with the originators of CLOVER and expressed my belief 
that hams need to quickly move to multi-tone modems of 16 to 39 tones 
Similar to the MIL-STD-188-110c type modems. Shortly after that I 
began corresponding with several members on the TAPR HFSIG. 


I am particularly impressed to see that HAL is moving up to higher 
bit rates and now has an external clover board...this is very 
important in emergency communications. 


I am presenting a program on HF digital communications to the San 
Antonio Radio Club next month and will use as a major part of my 
presentation the information (papers) supplied by HAL on the CLOVER 
system had were re-prints of magazine articles. I would be most 
interested in obtaining the same type of information about Q-CLOVER. 


While I was Chief of Communications Maintenance for the 32nd 
Aeromedical Evacuation Gp (and senior communicator in the AF 
Aeromedical Evacuation System) I pushed for use of the 
MIL-STD-188-110c modems (16/39 tone and serial tone) use, but the 
price limited our obtaining the modems (about $10K at the time). Our 
requirement was 2400 BPS data thruput under adverse HF conditions at 
the 100 Watt power level. As deputy communications director for the 
San Antonio Emergency Management Communications Gp (pronounce that 
Civil Defense Communications) I see the above requirement for our use, 
especially in providing command and control communications from the 
Texas Gulf Coast back to San Antonio during hurricanes. 


Additionally, we have a requirement to run TCP/IP on HF...3200 BPS 
(assuming 1000 BPS for FEC) would meet that need. Please consider 
writing encapsulation software for the CLOVER-200 (Q-CLOVER) modem 
allowing it to run TCP/IP over HF. 


I am looking forward to hearing from you. The top part of my tower 
is still on the ground so my LP is still on the ground and I won't be 


able to hear your test. 


Best Regards, 


Walt DuBose 


In Frode's message of 23 Feb 1996 at 0947 CST, he writes: 


VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV 


On Thu, 22 Feb 1996, Johan Forrer wrote: 


I don't think this is a typo about the 2kHz Clover units - could you please 
expand a bit on what this is about. I thought HAL was pushing for 500 Hz 
bandwidth, but perhaps this is a new development? Four parallel Clover 
channels = 2 kHz bandwidth, at roughly 800 x 4 = 3200 bps. In my opinion, 
this is a welcome and needed step in the right direction. 


VV VV VV 


Here is some info distributed on the WUN Mailing list: 


>From BrunoUSA@aol.comFri Feb 23 11:21:58 1996 

Date: Wed, 24 Jan 1996 00:05:05 -0500 

>From: BrunoUSA@aol.com 

To: wun@grove.net 

Subject: [WUN] CLOVER-2000 (Q-CLOVER, Quad-CLOVER) listen-in ! 


If any of you are interested in "listening" to this new digital 
communications mode, tune your receivers to 11.0776 MHz or 10.3976 MHz, USB 
starting at 09h00 PST, Wednesday, January 24th. 


We will be experimenting the "beta" CLOVER-2000 (Q-CLOVER or Quad-CLOVER as 
it is also called) between our base in Escondido, California and a remote 
site in Illinois. 

CLOVER-2000 is similar to standard CLOVER except that it is 2KHz wide and is 
comprized of 8-tones (both phase & amplitude modulated)... it sounds quite 
different friom "regular" CLOVER. 

We are running 100 Watts PEP into a 16 element LPDA @ 65' in California. Our 
counterpart also has a LPDA... both are aimed at each other. 


This will give you an opportunity of "listening" to this new "sound"... by 
the way, if you monitor these frequencies, you will also hear other more 
exotic modes (39-tone, ALE, serial-tone, cypher, etc.) as they are part of 
our assigned HF test frequencies. 


If you hear us... drop me e-mail at: bhaineau@cts.com and I will confirm 
valid reports (describe the "sounds" you are hearing... and if you do manage 
to decode the traffic, you will earn extra brownie points ;-) 


Good listening... 


Bruno Haineault 


> This is the WUN mailing list. 

> To post to the list, send a e-mail to : wun@grove.net 

> To unsubscribe the list, send a mail to: majordomo@grove.net 

> with only "unsubscribe wun" in the BODY of the e-mail. 

> —— 

> 

> 

> weeeeew eee ewww ewww eww ew ew = 

> 

> 73's Frode 

> 

> 

> Frode Weierud Phone : 41 
22 7674794 

> CERN, SL Fax : 41 22 7679185 
> 


From karn@qualcomm.com Fri Feb 23 18:46:26 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.4/8.7.3/1.8) with ESMTP id SAA22678 for <hfsig@tapr.org>; Fri, 23 Feb 1996 
18:46:24 -0600 (CST) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.3/8.7.2/1.6.1) id 
QAA05605; Fri, 23 Feb 1996 16:45:51 -0800 (PST) 

Date: Fri, 23 Feb 1996 16:45:51 -0800 (PST) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199602240045.QAA05605@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <9602161748.AA11073@ucs.orst.edu> (forrerj@ucs.orst.edu) 

Subject: Re: [HFSIG:893] Re: Sync Vectors for HF Digital 


>It appears that there are some choices for the frame sync sequence. The 
>13-bit Barker sequence looks like a good choice - unless someone has a good 
>argument against it. Detecting the sequence or deriving bit timing, is where 


Well, my main objection to Barker sequences is that the longest known 
Barker sequence isn't very long. Since the sync vectors are sent 
without ECC, and because the ECC code rate might be very low, you need 
extreme robustness in your sync vector. That argues for a fairly long 
sync vector, much longer than 13 bits. 


You can think of a PN sync sequence as a "Spread spectrum burst" conveying 
one bit of information ("the packet starts HERE") with a considerable 
processing gain equal to the number of bits in the sequence. A 64-bit PN 
sequence gives a processing gain of 64:1 or about 18 dB, which should be 
enough to keep working reliably even at the extremely low symbol S/Ns 
implied by powerful, low rate ECC. 


Phil 
From hstr@gil.com.au Fri Feb 23 18:49:23 1996 


Received: from iccu6.ipswich.gil.com.au (iccu6.ipswich.gil.com.au [203.1.75.10]) 
by tapr.org (8.7.4/8.7.3/1.8) with ESMTP id SAA23074 for <hfsig@tapr.org>; Fri, 23 


Feb 1996 18:49:16 -0600 (CST) 

Received: from csip11.ipswich.gil.com.au (cs1p11.ipswich.gil.com.au 

[203.1.75.158]) by iccu6.ipswich.gil.com.au with SMTP id TAA17928 
(8.6.12/IDA-1.6 for <hfsig@tapr.org>); Fri, 23 Feb 1996 19:48:42 -0500 

Message-ID: <199602240048.TAA17928@iccu6.ipswich.gil.com.au> 

Comments: Authenticated sender is <hstr@mail.ipswich.gil.com.au> 

From: "Helmut Strickner" <hstr@gil.com.au> 

To: hfsig@tapr.org 

Date: Sat, 24 Feb 1996 10:48:59 +1000 

Subject: EVM56002 connecting to printer port 

Priority: normal 

X-mailer: Pegasus Mail for Windows (v2.23) 


Hi 


I have downloaded the latest evm27.zip file from the Motorola bubfile 
archive (design.NET site) and found an archive in it called spec.zip. 


It contains some programmes, one of them is a frequency domain plot 
program which runs on the PC. In this example the FFT is performed on 
the EVM56002 which is connected to the PC parallel port via a cable 
from J7. There is a file in the archive called spec2.doc which contains 
the description of the program and shows how to connect the Port B of 
the DSP56002 which is J7 to the parallel port on the PC. 


The problem is that I am unable to read this doc file, it is not in 
word format but has a label at the beginning of the file <MakerFile 
4.0K>. Can somebody please tell me how to read or convert this file 
into a readable and printable format? It contains some graphics about 
the cable connection from J7 to the parallel port. 


If someone has already converted this file is it possible to upload 
it to hfsig/upload directory please. 


I think to ask Motorola to post this file in a 'standard' format will 
take months of waiting. It took them two months to sort out the 
problems with the corrupt evm27.exe file in the bubfile archive. 


Helmut 


From kurpiers@zeus.uet.e-technik.th-darmstadt.de Sat Feb 24 00:26:19 1996 
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by 
tapr.org (8.7.4/8.7.3/1.8) with SMTP id AAA11606 for <hfsig@tapr.org>; Sat, 24 Feb 
1996 00:26:16 -0600 (CST) 

Received: from zeus (zeus.uet.e-technik.th-darmstadt.de [130.83.18.75]) by 
rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id HAA08746 for 
<hfsig@tapr.org>; Sat, 24 Feb 1996 07:26:12 +0100 

Received: from hades.uet.e-technik.th-darmstad (hades.uet.e-technik.th- 
darmstadt.de [130.83.18.78]) by zeus (8.7.1/8.6.9-HRZ) with ESMTP id HAA20830 for 
<hfsig@tapr.org>; Sat, 24 Feb 1996 07:26:11 +0100 

Received: (from kurpiers@localhost) by hades.uet.e-technik.th-darmstad 
(8.7.1/8.7.1-HRZ-Fwd2.2) id HAA21288; Sat, 24 Feb 1996 07:26:10 +0100 


Date: Sat, 24 Feb 1996 07:26:10 +0100 (MEZ) 

From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:904] Re: Sync Vectors for HF Digital 

In-Reply-To: <199602240045 .QAA05605@servo. qualcomm. com> 

Message-ID: <Pine.A32.3.91.960224072316 .19236A-100000@hades.uet.e-technik. th- 
darmstadt.de> 

MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Fri, 23 Feb 1996, Phil Karn wrote: 


>It appears that there are some choices for the frame sync sequence. The 
>13-bit Barker sequence looks like a good choice - unless someone has a good 
>argument against it. Detecting the sequence or deriving bit timing, is where 


Well, my main objection to Barker sequences is that the longest known 
Barker sequence isn't very long. Since the sync vectors are sent 
without ECC, and because the ECC code rate might be very low, you need 
extreme robustness in your sync vector. That argues for a fairly long 
sync vector, much longer than 13 bits. 


VVVV VV VV VV 


The longest known binary Barker sequence is 13 bits. But there are lots 

of longer Generalized Barker sequences. The longest I know is 36 bits long. 
As we don't have to stick to binary sequences there is a possibility to 
use Generalized Barker sequences. 


You can think of a PN sync sequence as a "Spread spectrum burst" conveying 
one bit of information ("the packet starts HERE") with a considerable 
processing gain equal to the number of bits in the sequence. A 64-bit PN 
sequence gives a processing gain of 64:1 or about 18 dB, which should be 
enough to keep working reliably even at the extremely low symbol S/Ns 
implied by powerful, low rate ECC. 


Phil 


VV VV VV V VV 


Ok, from a practical point of view PN sequences seem to be better. 


73' Alexander> 


Purses eee fee ee ee Se tousee see eSe fee tose he eee hese ee Eee aoe * 
| Alexander F. Kurpiers | | 
| Institut £. Uebertragungstechnik | Voice: +49-6151-162369 | 
| u. Elektroakustik | Fax : +49-6151-165545 

| Merckstrasse 25 | EMail: a.kurpiers@uet.th-darmstadt.de | 
| D-64283 Darmstadt (Germany) | Hamradio: dl8aau@dbOzdf.#rpl.deu.eu 

Fests soe see ee ee Poses shee eee ee eee ete * 


From k4gvo@america.net Sat Feb 24 05:22:43 1996 


Received: from america.net (atl1.america.net [199.170.121.2]) by tapr.org 
(8.7.4/8.7.3/1.8) with SMTP id FAA21207 for <hfsig@tapr.org>; Sat, 24 Feb 1996 
05:22:41 -0600 (CST) 

Message-Id: <199602241122.FAA21207@tapr.org> 

Received: from k4gvo (pm1-5.america.net [199.170.121.105]) by america.net 
(8.6.10/8.6.9) with SMTP id GAAQ0674; Sat, 24 Feb 1996 06:28:06 -0500 
Sender: <k4gvo@atl1.america.net> 

From: "Jim Lynch" <k4gvo@america.net> 

To: "Helmut Strickner" <hstr@gil.com.au>, hfsig@tapr.org 

Date: Sat, 24 Feb 1996 06:21:13 +0000 

Subject: Re: [HFSIG:905] EVM56002 connecting to printer port 
Reply-to: k4gvo@america.net 

Priority: normal 

X-mailer: Pegasus Mail/Windows (v1.22) 


> Date: Fri, 23 Feb 1996 19:05:35 -0600 (CST) 

> Reply-to: hfsig@tapr.org 

> From: "Helmut Strickner" <hstr@gil.com.au> 

> To: hfsig@tapr.org 

> Subject: [HFSIG:905] EVM56002 connecting to printer port 
Hi 


I have downloaded the latest evm27.zip file from the Motorola bubfile 
archive (design.NET site) and found an archive in it called spec.zip. 


It contains some programmes, one of them is a frequency domain plot 
program which runs on the PC. In this example the FFT is performed on 
the EVM56002 which is connected to the PC parallel port via a cable 
from J7. There is a file in the archive called spec2.doc which contains 
the description of the program and shows how to connect the Port B of 
the DSP56002 which is J7 to the parallel port on the PC. 


The problem is that I am unable to read this doc file, it is not in 
word format but has a label at the beginning of the file <MakerFile 
4.0K>. Can somebody please tell me how to read or convert this file 
into a readable and printable format? It contains some graphics about 
the cable connection from J7 to the parallel port. 


If someone has already converted this file is it possible to upload 
it to hfsig/upload directory please. 


I think to ask Motorola to post this file in a 'standard' format will 
take months of waiting. It took them two months to sort out the 
problems with the corrupt evm27.exe file in the bubfile archive. 


VV VV VV VV VV VV VV VV VV VV VV VV VV 


Helmut 

It sounds like that may be a Frame Maker file. I use (rarely) frame 
maker at work and might be able to translate the file into another 
format, but I'm not sure about the legality of re-distributing it. 
I've seen a "frame viewer" somewhere recently, but don't remember 
where it was. It ran on apc, so maybe this will jog someone's 
memory. I'll keep my eyes open. 


Jim. 
Jim Lynch Fayetteville, GA K4GV0O 
'86 GL1200I k4gvo@america.net 44.36.34.20 


From gc@fox.cen.com Sat Feb 24 11:11:42 1996 
Received: from uu5.psi.com (uu5.psi.com [38.145.226.3]) by tapr.org 
(8.7.4/8.7.3/1.8) with SMTP id LAAQ2584 for <hfsig@tapr.org>; Sat, 24 Feb 1996 
11:11:39 -0600 (CST) 
Received: from fox.cen.com by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; 
id AA27498 for hfsig@tapr.org; Sat, 24 Feb 96 12:11:32 -0500 
Received: by cen.com (4.1/SMI-4.1) 
id AAQ4594; Sat, 24 Feb 96 12:11:31 EST 
Date: Sat, 24 Feb 96 12:11:31 EST 
From: gc@fox.cen.com (Gary Chatters) 
Message-Id: <9602241711.AA04594@cen.com> 
To: hfsig@tapr.org 
Subject: FrameReader (Was: EVM56002 ...) 


>It sounds like that may be a Frame Maker file. I use (rarely) frame 
>maker at work and might be able to translate the file into another 
>format, but I'm not sure about the legality of re-distributing it. 
>I've seen a "frame viewer" somewhere recently, but don't remember 
>where it was. It ran ona pc, so maybe this will jog someone's 
>memory. I'll keep my eyes open. 


FrameReader is available via anonymous ftp at ftp.frame.com. 

cd to /pub/techsup/product_updates/dos and get the file: reader.zip. 
PKZIP is available on some other branch of the /pub/techsup tree 

to unzip the file. Even in its compressed format this is a 4.7MB file. 
mac and unix versions available. 


Frame also has a FrameViewer which costs about $20-$30. 


On a more general note: Microsoft Word, Frame, Mathematica, and Adobe 
(and others) all have free or cheap viewers available. 


Gary 


From srbible@mindport.net Sat Feb 24 17:07:12 1996 

Received: from polaris.mindport.net (root@polaris.mindport.net [205.219.167.2]) by 
tapr.org (8.7.4/8.7.3/1.8) with SMTP id RAA16333 for <hfsig@tapr.org>; Sat, 24 Feb 
1996 17:07:06 -0600 (CST) 

Received: from default (synapse-71.mindport.net [205.219.167.130]) by 
polaris.mindport.net (8.6.12/8.6.12) with SMTP id SAA27415 for <hfsig@tapr.org>; 
Sat, 24 Feb 1996 18:07:05 -0500 

Posted-Date: Sat, 24 Feb 1996 18:07:05 -0500 

Message-Id: <1.5.4b11.32.19960224230716 .0067414c@mindport.net> 

X-Sender: srbible@mindport.net 

X-Mailer: Windows Eudora Light Version 1.5.4b11 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sat, 24 Feb 1996 18:07:16 -0500 


To: hfsig@tapr.org 
From: "Steven R. Bible" <srbible@mindport.net> 
Subject: Re: [HFSIG:908] FrameReader (Was: EVM56002 ...) 


Does anyone know of a postscript viewer/reader for Win95? And to make it 
even more challenging, can print to whatever Win95 printer driver is 
installed at the time. Either I have to purchase a postscript printer or 
convert postscript files to adobe PDF format. 


Thanks, Steve N7HPR 


>FrameReader is available via anonymous ftp at ftp.frame.com. 

>cd to /pub/techsup/product_updates/dos and get the file: reader.zip. 
>PKZIP is available on some other branch of the /pub/techsup tree 

>to unzip the file. Even in its compressed format this is a 4.7MB file. 
>mac and unix versions available. 

> 

>Frame also has a FrameViewer which costs about $20-$30. 

> 

>On a more general note: Microsoft Word, Frame, Mathematica, and Adobe 
>(and others) all have free or cheap viewers available. 

> 

>Gary 

> 

> 

> 


From hstr@gil.com.au Sun Feb 25 17:21:56 1996 
Received: from iccu6.ipswich.gil.com.au (iccu6.ipswich.gil.com.au [203.1.75.10]) 
by tapr.org (8.7.4/8.7.3/1.8) with ESMTP id RAA18356 for <hfsig@tapr.org>; Sun, 25 
Feb 1996 17:21:52 -0600 (CST) 
Received: from cs9p9.ipswich.gil.com.au (cs9p9.ipswich.gil.com.au [203.1.72.72]) 
by iccu6é.ipswich.gil.com.au with SMTP id SAA11458 
(8.6.12/IDA-1.6 for <hfsig@tapr.org>); Sun, 25 Feb 1996 18:21:21 -0500 
Message-ID: <199602252321.SAA11458@iccu6.ipswich.gil.com.au> 
Comments: Authenticated sender is <hstr@mail.ipswich.gil.com.au> 
From: "Helmut Strickner" <hstr@gil.com.au> 
To: hfsig@tapr.org 
Date: Mon, 26 Feb 1996 09:21:43 +1000 
Subject: Re: Re: FrameReader (Was: EVM56002 ...) 
Priority: normal 
X-mailer: Pegasus Mail for Windows (v2.23) 


Does anyone know of a postscript viewer/reader for Win95? And to make it 
even more challenging, can print to whatever Win95 printer driver is 
installed at the time. Either I have to purchase a postscript printer or 
convert postscript files to adobe PDF format. 


VV VV VV 


Thanks, Steve N7HPR 


> 

Have you tried Ghostview and Ghostscript ? They are available under 
the GNU agreement on a number of sites. I am not sure whether there 
is a version out yet which runs under Win95. 


As for the Frame Reader programme I have spent about 4 hours 
downloading it before the ftp stalled around the 4Mb mark. 

The Frame Reader is freely available and the size of the file is abt. 
4.6MB. Perhaps I will have another try on a luckier day. 


Helmut 

> 

> 

> >FrameReader is available via anonymous ftp at ftp.frame.com. 

> >cd to /pub/techsup/product_updates/dos and get the file: reader.zip. 
> >PKZIP is available on some other branch of the /pub/techsup tree 

> >to unzip the file. Even in its compressed format this is a 4.7MB file. 
> >mac and unix versions available. 

>> 

> >Frame also has a FrameViewer which costs about $20-$30. 

>> 

> >On a more general note: Microsoft Word, Frame, Mathematica, and Adobe 
> >(and others) all have free or cheap viewers available. 

ae 

> >Gary 

>> 

>> 

>> 

> 

> 

> 


From jbloom@usa.nai.net Mon Feb 26 05:00:41 1996 
Received: from usa.nai.net (usa.nai.net [204.71.21.10]) by tapr.org 
(8.7.4/8.7.3/1.8) with SMTP id FAA19402 for <hfsig@tapr.org>; Mon, 26 Feb 1996 
05:00:38 -0600 (CST) 
Received: from jbloom.nai.net (jbloom.nai.net [204.71.21.17]) by usa.nai.net 
(8.6.5/8.6.5) with SMTP id FAAQ9386 for <hfsig@tapr.org>; Mon, 26 Feb 1996 
@5:51:45 -0500 
Received: by jbloom.nai.net with Microsoft Mail 

id <01BBO40F .32048C40@jbloom.nai.net>; Mon, 26 Feb 1996 05:56:39 -@500 
Message-ID: <Q1BBO40F .32048C40@jbloom.nai.net> 
From: Jon Bloom <jbloom@usa.nai.net> 
To: "'hfsig@tapr.org'" <hfsig@tapr.org> 
Subject: RE: [HFSIG:910] Re: Re: FrameReader (Was: EVM56002 ...) 
Date: Mon, 26 Feb 1996 05:54:01 -0500 
MIME-Version: 1.0 
Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BBO40F .3236E6E0" 


wore -- = NextPart_000_01BBO40F .3236E6E0 
Content-Type: text/plain; charset="us-ascii" 


Content-Transfer-Encoding: quoted-printable 


Helmut Strickner[SMTP:hstr@gil.com.au] wrote: 

> 

> 

>> Does anyone know of a postscript viewer/reader for Win95? And to = 
make it 

>> even more challenging, can print to whatever Win95 printer driver is 
>> installed at the time. Either I have to purchase a postscript = 
printer or 

>> convert postscript files to adobe PDF format. 

>>=20 

>> Thanks, Steve N7HPR 

>>=20 

>Have you tried Ghostview and Ghostscript ? They are available under=20 
>the GNU agreement on a number of sites. I am not sure whether there=20 
>is a version out yet which runs under Win95. 


Yes, the 32-bit Ghostscript 3.53 runs under Win95. I use it often, along = 
with GSView 1.4, to attach preview bitmaps to EPS files and to view = 
Postscript files. (I don't use it to print since I have a Postscript = 
printer, but it will print to a Windows printer.) 


See http://www.cs.wisc.edu/~ghost/ 
--Jon 


woo -- = NextPart_000_01BBO40F .3236E6E0 
Content-Type: application/ms-tnef 
Content-Transfer-Encoding: base64 


eJ8+TickAQaQCAAEAAAAAAABAAEAAQeQBgEATAAAASAQAAAAAAADOAAENSAQAASAAAATAASABBIJAG 
AAABAAABAAAADAAAAAMAADADAAAACWAPDSAAAAACAL8PAQAAADSAAAAAAAAASSSfpL6jEBmdbgDd 
AQOUASAAAABoZnNpZOBOYXByLm9yZwBT TVRQAGhmc21nQHRhcHIub3 InAAAeAATWAQAAAAUAAABT 
TVRQAAAAAB4AAZABAAAADWAAAGHmc21nQHRhcHIub3JnAAADABUMAQAAAAMA/ g8GAAAAHSABMAEA 
AAARAAAAI2hmc21nQHRhcHIub3 In JwAAAAACAQSWAQAAABQAAABT TVRQOKhHGUOLHQFRBUFIuT1JH 
AAMAADkAAAAACWBAOSEAAAACAELY PAQAAAAQAAAAAAAADWSKBC TAHABSAAABIJUEOUTW1 IJ cm9zb2Z0 
TE1ThawWwuTm90ZQAxCAEE gSAEAOAAAAF JFOIBbSEZTSUc60TEwXSBSZTogUmU6IEZyYW11UmVhZGVy 
IChXYXM6IEVWTTU2MDAyIC4uLikA8w4BBYADAA4AAADMBwIAGgAFADYAAQABACWBASCAAWAOAAAA 
ZACCABOABQAVAC TAAQBGAQE J SAEATQAAADA4OUUWQTQ4MDA3MENGMTE5MjUINDQONTUZNTQwMDAwW 
AKwGAQOQBgAQBQAAE gAAAASATWAAAAAAAWAmMAAAAAAALACKAAAAAAAMANSAAAAAAQAASAGCO/ xw4 
BLSBHgBwAAEAAAA4ZAAAAUKU6GIFtIRINIRZOSMTBdIFILOIBSZTogRnJhbWVSZWFkZXIgkFdhczog 
RVZNNTYwMDIgLi4ukKQACAXEAAQAAABYAAAABuwQ4vLJICp4JcAARZ5IVREVTVAAAAAACAB4MAQAA 
AAUAAABTTVRQAAAAAB4AHwWwBAAAADWAAAGpibG9vbUBuYWkubmVOAAADAAYQs6qTVWMABxCQASAA 
HgATEAEAAABLAAAASEVMTVVUULRSSUNLTkKVSUO1UUDpIULRSQEdITENPTUFVV1JPVEU6RE9FUOFO 
WUIDRUtOTIdPRkFQTINUUONSSVBUVK1IFVOVSL1IJFQURFUkKZPULdITjkI1POFORFRPTUFLRULURQAA 
AAACAQKQAQAAAHKDAAB1AWAA+AYAAE xaRnwWhIpmD/wAKAQ8CFQKoBesCgwBQAVIJAgBjaArAc2VO 
Mj cGAAbDAoMyA8UCAHBy QnER4nNOZWOCgZM3 AUQHEWKDNARGEZMxIHcLIVQeyAoB9CoAIzwnZ0/EY 
DzZIINQKACoENSQtg4G5nMTAZFFALChVhBQvy YwBALTEhLbGOSdQVAU3QFEGNIbgEEKFtTTVRQOmhR 
E8ByQGcDEC4FoG3ALmF1XSB3A2ATOHO6CoU+G88N8BNQH4F Jj /wVACocb7yA/IU8ixXyNvJHywPiBE 
bweRAHB5AiCUZSAdSG8H4G9mKRBY IHBvE8AE9XY [kKH£VBJAVGBBhBIEgAhAFwEJXC4A5NT8gFLBu 
oGQgdG8gAMBrkXA8axQ1XyZvI380g2V2nwnwLOAFSC1lwEXFsbAnw+x6gGxASMXADkRNQC4AFQPOs 
wXcREBPQMPAr5TKEFLH+ZAUQM3IEAC1vLn8vj yiDvwuAE8Axoiy gMOASsGgpcOpOB3EULGBFLUA5 


SAXA3EkKSEYAw8CyycAhwEXH/EbAqDDQWBbA1LZY/NO80g90F0G4zcTxxKkhmAxAHkRMswStwb2Ip 
cFBERvMrsgDAdC49Pz5PP180gy9Dj0Sf£Ra80g10REG5rHnMyMB1gMOEHSDdIUP5SRw9THOkvRIOM 
£02PINZ2SDrCKUB1LLAI gSygR/50KkEq4ikRU2UE9SxQSoD8ZXkpEDFROSALcAtgAmD9KXB1ILIAW 
SU8/UEORXyUh8T1lyRO5VKRAJwgeAMSHZA1AqAW51BtA84inwAJDNE9BZOfA6kKGFtW5AfgP9cMAhw 
KXAZIBHAO1I6Qilw/1b£V+9Y / yYUHRBAAGATNxXAJB3W1EIYAVAGRHAMXEdkGj 8IHIJWcAQgVnQsAON4 
G587HKNk1VKHkDIwOXIzMgwtYilAVFszLjUze2N/XJJ105FnwSngE9BudzIwBOACIGcfUDoxU3BT 
41ZT4j EuNGchQ1LECQH8A0GNSE1AW4FPiZ7EAWHD5QiNFUAXwQeRUTizBU9M2UEFNOfAOOpBCgG4n 
nwVAakU7AjKjJAJBuYylw3zqVKhBvyTQVMjBiHTFnwb8D8DGwMogqECwBQoB3BCB5NBUUuKWSVZIUG 
YClwaMECQHA6Ly93eLAeOBNc gAPxYy4J gsHUvfopnUS5IvdywtLUoCIAt3LBcxAHxwAAAAAWAQEAAA 
AAADABEQAAAAAEAABZASCNzZVNwS7AUAACDASCNzVNwS7AR4APQABAAAABQAAAF JFOiAAAAAAUHU= 


ee eeee = _NextPart_000_01BBO40F .3236E6E0- - 


From FORRERJ@frl.orst.edu Mon Feb 26 10:43:00 1996 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
tapr.org (8.7.4/8.7.3/1.8) with SMTP id KAA0Q1874 for <hfsig@tapr.org>; Mon, 26 Feb 
1996 10:42:58 -0600 (CST) 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id IAA23942 for <hfsig@tapr.org>; Mon, 26 Feb 1996 
08:38:55 -0800 
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21); 
26 Feb 96 08:49:51 PST8PDT 
Received: from SpoolDir by FRL (Mercury 1.21); 26 Feb 96 08:49:27 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Mon, 26 Feb 1996 08:49:17 -0800 
Subject: Re: [HFSIG:904] Re: Sync Vectors for HF Digital 
Priority: normal 
X-mailer: Pegasus Mail v3.22 
Message-ID: <39F223B3805@frl.orst.edu> 


Hi Phil, 


For the same argument, I assume that reverse channel signaling for an 
ARQ system needs the same considerations as that is also an unprotected 
sequence? 


Any suggestions on what would be suitable there? 


>It appears that there are some choices for the frame sync sequence. The 
>13-bit Barker sequence looks like a good choice - unless someone has a good 
>argument against it. Detecting the sequence or deriving bit timing, is where 


Well, my main objection to Barker sequences is that the longest known 
Barker sequence isn't very long. Since the sync vectors are sent 
without ECC, and because the ECC code rate might be very low, you need 
extreme robustness in your sync vector. That argues for a fairly long 
sync vector, much longer than 13 bits. 


You can think of a PN sync sequence as a "Spread spectrum burst" conveying 
one bit of information ("the packet starts HERE") with a considerable 


VVVV VV VV VV VV NV 


> processing gain equal to the number of bits in the sequence. A 64-bit PN 
> sequence gives a processing gain of 64:1 or about 18 dB, which should be 
> enough to keep working reliably even at the extremely low symbol S/Ns 

> implied by powerful, low rate ECC. 

> 

> Phil 

> 

> 

--Johan 


From NOAOT@aol.com Tue Feb 27 11:38:26 1996 

Received: from mail04.mail.aol.com (mail04.mail.aol.com [152.163.172.53]) by 
tapr.org (8.7.4/8.7.3/1.8) with SMTP id LAA26762 for <hfsig@tapr.org>; Tue, 27 Feb 
1996 11:38:24 -0600 (CST) 

From: NOAOT@aol.com 

Received: by mail04.mail.aol.com (8.6.12/8.6.12) id MAA17623; Tue, 27 Feb 1996 
12:37:20 -0500 

Date: Tue, 27 Feb 1996 12:37:20 -0500 

Message-ID: <960227123719_334589791@mail04.mail.aol.com> 

To: forrerj@frl.orst.edu 

cc: hfsig@tapr.org, amsat-bb@amsat.org 

Subject: Re: [HFSIG:896] QST tidbits 


In a message dated 96-02-21 14:08:36 EST, you write: 


>Wonder if you had a chance to look at the latest issue of QST yet? 
> 


Hi Johan-- 


I haven't talked to you for ages, but have been following your comments here 
on the HFSIG. Lots of neat stuff going on! 


Here's another tidbit from the bottom of page 183 of Jan 96 QST: Brian 
Beezley, K6STI, is offering an DSP RTTY package which uses the common SB-16 
sound card. He describes a graphical FFT tuning indicator and many other 
features. He doesn't say anything about amtor/pactor, though. 


Have you or any of the others tried out this software? I have a sb compatible 
chip in my Pentium notebook, and I realized that if it really works, all I 
have to do is plug my radio directly into the mike and speaker jack of the 
notebook, to be on the air! How's that for simple and portable? 

Now if someone would just write a 9600 baud modem for the pacsats using the 
SB-16 and/or Pentium, I could throw out the DSP 2232 (which AEA seems to have 
abandoned) along with all the rest of the external modems! 

73's, 


--Bob Carlson, nOaot@amsat.org 


From cbuttsch@biggulp.callamer.com Tue Feb 27 12:46:56 1996 


Received: from biggulp.callamer.com (cbuttsch@biggulp.callamer.com [199.74.141.2]) 
by tapr.org (8.7.4/8.7.3/1.8) with ESMTP id MAA29528 for <hfsig@tapr.org>; Tue, 27 
Feb 1996 12:46:54 -0600 (CST) 

Received: (from cbuttsch@localhost) by biggulp.callamer.com (8.7.4/8.7.3) id 
KAA29920; Tue, 27 Feb 1996 10:46:45 -@Q800 (PST) 

Date: Tue, 27 Feb 1996 10:46:45 -@800 (PST) 

From: Clifford Buttschardt <cbuttsch@biggulp.callamer.com> 

To: NOAOT@aol.com 

cc: hfsig@tapr.org 

Subject: Re: [HFSIG:913] Re: QST tidbits 

In-Reply-To: <960227123719_334589791@mail04.mail.aol.com> 

Message-ID: <Pine.OSF.3.91.960227104126 .16938F -100000@biggulp.callamer.com> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


As you, I am most interested in Brian Beesley's efforts using the sound 
card instead of some of the DSP units that have attempted to do 9600, 
Amtor/Pactor. These tasks should have already been accomplished by the 
DSP 93 platform by have not! If this sound card approach does work, I'd 
be most interested in knowing that fact AND knowing just how difficult it 
might be to program for BPSK, DBPSK and similar protocols. 

Cliff Buttschardt W6HDO 


From forrerj@ucs.orst.edu Tue Feb 27 17:32:39 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.4/8.7.3/1.8) with SMTP id RAA12043 for <hfsig@tapr.org>; Tue, 27 Feb 1996 
17:32:36 -0600 (CST) 
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM) 

id AA12695; Tue, 27 Feb 1996 14:11:44 -0800 
Date: Tue, 27 Feb 1996 14:11:42 -0800 (PST) 
From: Johan Forrer <forrerj@ucs.orst.edu> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:914] Re: QST tidbits 
In-Reply-To: <Pine.OSF.3.91.960227104126 .16938F-100000@bigsulp.callamer.com> 
Message-Id: <Pine.OSF.3.91.960227132050 .11393C-100000@ucs.orst.edu> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi Cliff, 
On Tue, 27 Feb 1996, Clifford Buttschardt wrote: 


As you, I am most interested in Brian Beesley's efforts using the sound 
card instead of some of the DSP units that have attempted to do 9600, 
Amtor/Pactor. These tasks should have already been accomplished by the 
DSP 93 platform by have not! If this sound card approach does work, I'd 
be most interested in knowing that fact AND knowing just how difficult it 
might be to program for BPSK, DBPSK and similar protocols. 

Cliff Buttschardt W6HDO 


VV VV VV VV WV 


> 


couple of things to consider: 


I have been hearing great things about Brian's program - a nice 

achievement. For RTTY, however, it is OK to "copy behind" even by as much 

as one symbol (baud) time. That is not workable for an ARQ system where 

the additional delay (as much as 10 ms) will most definately upset the tight 
timing cycle. However, I'm sure that it is only a matter of time 

until when we will see a solution. 


You probably are aware of Bill de Carle's, VE2IQ, work with CCW and BPSK 
using a PC platform for doing DSP - perhaps pushing it to the limit, however, 
as the processing speeds go up and prices drop, who knows, one day we might 
all be doing it that way. As Phil has often said, we can get a lot of 
amateurs interested in participating if we can do advanced DSP on a PC 
rather than invest in additional external equipment. 


Venturing off the HF digital topic, the issue of doing a fully featured 
9600 baud modems on the DSP-93 is not as obvious. I have looked 

into this possibility with the intention of doing this, but must agree 

with the DSP-93 experts that it is, to say the least, more than a 
challenge. And not for lack of efforts either. The DSP-93 uses a CODEC that 
is programmed at a fixed A/D rate that is not a multiple of the 9600 baud 
clock. This means that it is not possible to ever achieve perfect sync to 
extract exact bit edges. The option that the designers had was to 
oversample the signal in order to increase resolution and thus reduce the 
amount of bit edge jitter. The price to pay is that this eats 

up a lot of DSP clock tics and thus leaves little prospect for doing things 
like HDLC on the DSP. I hope that I have summarized this accurately - 

this is what Frank Perkins, one of the DSP-93 modem designers shared with me. 
Someone may want to comment on this. 


This problem is not unique to the DSP-93 either. Have a look at the new 
AEA DSP-232 and you will see that they still have an HDLC chip on the 
board. Guess why? If you look a bit further at other 9600 baud DSP 
applications like for instance the DSP sound card, you see similar 
things such as HDLC emulation being done on the PC, however few do 
attempt this on the DSP. 


There is an exception though. With the 9600 baud G3RUH modem for the 
Motorola EVM, Jarkko, OH2LNS, pulled some clever tricks out of the 

hat by utilizing 56K features. He has managed to implemnt both the 

9600 baud modem, HDLC decoder and 19.2K KISS interface all on the DSP. In my 
humble opinion, this is only possible due to the 56K architecture. For 
instance, it has an on-chip UART that takes care of the serial interface. 
Anyone that has succeeded in building a bit-banger UART on a DSP where 
there are high rate interrupts running at the same time, knows the value 
of this bit of hardware. The other bit of hardware that helps here is 

the high speed serial interface for dealing with the CODEC that makes it 
possible to implement very efficient interrupt service routines. In 
addition, the instruction set of this chip is more like a microcontroller 
than a DSP, though works like a DSP. This 9600 baud modem runs on the 

DSP4 which has a 27 MHz clock - the latest version of the EVM has a 66 MHz 
chip, just to give you an idea that the chip is not strapped for clock 
cycles. 


My $0.02, for what it is worth. 


It is important to keep in mind that each platform has its advantages and 
disadvantages. The potential is there, none of it is easy, and the learning 
curve is steep. But it is inviting and ready for exploring - if you have 
the time and patience. 


Good luck. 
--Johan, KC7WW 


From fperkins@onramp.net Tue Feb 27 20:03:54 1996 

Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by tapr.org 
(8.7.4/8.7.3/1.8) with ESMTP id UAA19779 for <hfsig@tapr.org>; Tue, 27 Feb 1996 
20:03:47 -0600 (CST) 

Received: from 199.184.212.226 (stockyard63.onramp.net [199.184.212.226]) by 
mailhost.onramp.net (8.7.3/8.6.5) with SMTP id UAA22485 for <hfsig@tapr.org>; Tue, 
27 Feb 1996 20:03:37 -0600 (CST) 

Date: Tue, 27 Feb 1996 20:03:37 -0600 (CST) 

Message-Id: <199602280203 .UAA22485@mailhost.onramp.net> 

MIME-Version: 1.0 

Content-Type: text/plain 

Content-Transfer-Encoding: 7bit 

From: fperkins@onramp.net 

Subject: Re: [HFSIG:915] Re: QST tidbits 

To: hfsig@tapr.org 

In-Reply-To: <Pine.OSF.3.91.960227132050.11393C-100000@ucs.orst.edu> 

X-Mailer: SPRY Mail Version: 04.00.06.17 


Hi Johan, 
Here is a couple of cents more: 


Re the DSP-93 and AMTOR, I have shown it receiving AMTOR using you TOR 
program on several of my DSP-93 videos as seen at the DCC and AMSAT 
conferences. The modem side was pretty easy - TOR does the hard part. 
I was just wondering if you had done any experimenting with the DSP-93 
TOR combo. 


Out of frustration in trying to define SW to do an AX.25 FCS 
calculation, I threw a bit of code together for the Bell 202 modem 
on the DSP-93, so I could push raw packets out the DSP-93 UART 

and get a look at the structure of the FCS. In case anyone is 
interested: 


All bytes in the packet EXCEPT the FCS are sent LSB ‘1st. 


The FCS is sent high byte first, MSB first. The AX.25 spec nicely 
gets around defining this by referring to an obscure CCITT spec. 


Based on this quick, rough hack, I don't think there would be any problem 
adding HDLC and KISS to the 300 and 1200 bps modems - if someone has the 


time and interest to pursue it. For the reasons you explained, I don't 
this is practical for 9600 bps. 


73 Frank WB5IPM 


From k6sti@n2.net Tue Feb 27 20:48:05 1996 

Received: from ravel.n2.net (ravel.n2.net [204.250.22.20]) by tapr.org 
(8.7.4/8.7.3/1.8) with SMTP id UAA21466 for <hfsig@tapr.org>; Tue, 27 Feb 1996 
20:48:01 -0600 (CST) 

Received: from ppp179.n2.net (ppp179.n2.net [204.250.22.179]) by ravel.n2.net 
(8.6.12/8.6.9) with SMTP id SAA26541 for <hfsig@tapr.org>; Tue, 27 Feb 1996 
18:48:37 -0800 

Date: Tue, 27 Feb 1996 18:48:37 -0800 

Message-Id: <199602280248.SAA26541@ravel .n2.net> 

X-Sender: k6sti@mail.n2.net 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: k6ésti@n2.net (Brian Beezley) 

Subject: Sound Blaster 


Johan, using the Creative Labs device driver, signal delay is about 500 ms 
on both transmit and receive for a 6-kHz sample rate. Most of this is in 
the DMA buffer, the size of which cannot be made less than 4096 bytes. The 
Creative Labs device driver is not easy to work with. I had a lot of 
trouble getting it to work reliably for continuous conversion despite three 
books of documentation and very accessible developer support. Some crucial 
parts of the documentation turned out to be in error and I had to discover 
this by experiment. Had I known all this before I started, I certainly 
would have rolled my own driver. In fact, I still may. 


Using the Creative Labs driver also ties you exclusively to Sound Blaster 
hardware. They have a very large share of the sound card market and their 
cards are inexpensive, so this isn't much of a problem for desktop 
applications. However, many notebook computers don't use the Creative Labs 
Vibra 16 chip. For these machines there's no way to add an alternate sound 
card and therefore no way to run a program written for the Creative Labs 
drivers. This issue has already come up for the Heard Island DXpedition 
that wants to take along high-performance RTTY without having to lug around 
external RTTY boxes. 


73--Brian, K6STI 
k6sti@n2.net 


From Robert.Glassey@nmp.nokia.com Wed Feb 28 06:01:14 1996 

Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.4/8.7.3/1.8) with SMTP id GAA17192 for <hfsig@tapr.org>; Wed, 28 Feb 1996 
06:01:05 -0600 (CST) 

From: Robert.Glassey@nmp.nokia.com 

Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id NAA11747 for <hfsig@tapr.org>; Wed, 


28 Feb 1996 13:33:37 +0200 
Received: from by samail01.nmp.nokia.com with SMTP 
(1.37.109.16/16.2) id AA272446978; Wed, 28 Feb 1996 13:29:38 +0200 
X-Openmail-Hops: 2 
Date: Wed, 28 Feb 96 11:31:30 +0000 
Message-Id: <H00002920138a6d3@MHS> 
In-Reply-To: <Pine.OSF.3.91.960227104126 .16938F -100000@biggulp.callamer.com> 
Subject: Re: QST tidbits 
Mime-Version: 1.0 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=ISO-8859-1; name="Re:" 
Content-Transfer-Encoding: quoted-printable 


Hi Everyone, 


It's about time I made myself know to more that just one or two of you, 
Since this is a pet topic of mine. I haven't had a chance to review 
Brians program, so I'm not sure what it is like or what it can do, but I= 


am also working on a RTTY/AMTOR/PACTOR soundblaster program, and am 
having some success, althought there is still plently of work to do. 


I've been following this group for a while now and am most interested in= 


what you guys are getting up to. As Phil has mentioned on this group a 
pentium/486 is quite capable of real DSP work, and in fact I have had a 
_very_ simple BPSK modem working on a 12 MHZ 286! Programming for the 
soundblaster at hardware level on a PC is not trivial, but it is quite 
possible, and the DMA and interupts of a PC can be used to our 
advantage. I program the interupt code in fixed point assembly and the 
UI/protocol stuff in C. 


As for when my program will be released, I'm not sure, but we're talking= 
6 months to a year away, unless I have a lot of unexpected time on my 
hands. At present my program does RTTY demod only, in a very crude 


manner. 


> As you, I am most interested in Brian Beesley's efforts using the 
sound card instead of some of the DSP units that have attempted to do= 


Vv 


9600, Amtor/Pactor. These tasks should have already been 

accomplished by the DSP 93 platform by have not! If this sound card 
approach does work, I'd be most interested in knowing that fact AND 
knowing just how difficult it might be to program for BPSK, DBPSK and= 


VVV WV 


> similar protocols. 
> Cliff Buttschardt W6HDO 
> — 


Cheers, 


Rob, GOVTQ 


From 72253.2602@compuserve.com Wed Feb 28 06:54:24 1996 
Received: from arl-img-5.compuserve.com (arl-img-5.compuserve.com [198.4.7.5]) by 
tapr.org (8.7.4/8.7.3/1.8) with SMTP id GAA19223 for <hfsig@tapr.org>; Wed, 28 Feb 
1996 06:54:22 -0600 (CST) 
Received: by arl-img-5.compuserve.com (8.6.10/5.950515) 
id HAAQ5901; Wed, 28 Feb 1996 07:53:45 -0500 
Date: 28 Feb 96 07:51:59 EST 
From: Peter Schulze <72253.2602@compuserve.com> 
To: HFSIG <hfsig@tapr.org> 
Subject: Re: [HFSIG:917] Sound Blaster 
Message-ID: <960228125158 72253 .2602_EHJ92-2@CompuServe. COM> 


Brian, 


you should consider to switch to Windows, there you have a very easy API to 
interface with the soundcards and you dont have to worry about the make and 
details. 

Together with the INTEL native DSP library you get a very easy no headache 
DSP setup. 


Peter 


From 72253.2602@compuserve.com Wed Feb 28 06:54:25 1996 
Received: from arl-img-5.compuserve.com (arl-img-5.compuserve.com [198.4.7.5]) by 
tapr.org (8.7.4/8.7.3/1.8) with SMTP id GAA19224 for <hfsig@tapr.org>; Wed, 28 Feb 
1996 06:54:22 -0600 (CST) 
Received: by arl-img-5.compuserve.com (8.6.10/5.950515) 
id HAAQ5923; Wed, 28 Feb 1996 07:53:47 -0500 
Date: 28 Feb 96 07:51:54 EST 
From: Peter Schulze <72253.2602@compuserve.com> 
To: HFSIG <hfsig@tapr.org> 
Subject: Digital Journal 
Message-ID: <960228125153_72253 .2602_EHJ92-1@CompuServe. COM> 


>You mentioned the digital journal in a TAPR 
>SIG .... who's digital journal... available in US??? 


The digital journal is the monthly publication of : 


International Digital Radio Association 
P.O. Box 2550 

Goldenrod, Florida 32733-2550 -- U.S.A. 
Office: +1-407-677-7000 

Fax: +1-407-671-0194 

Internet E-Mail Address: adrs@iea.com 
WWW Page: http://www.iea.com/~adrs 


The journal has its own WWW page: 
http: //home.earthlink.net/~n2hos/ 


73 Peter TY1PS 


From forrerj@ucs.orst.edu Wed Feb 28 10:58:31 1996 
Received: from ucs.orst.edu (forrerj@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.4/8.7.3/1.8) with SMTP id KAA29983 for <hfsig@tapr.org>; Wed, 28 Feb 1996 
10:54:56 -0600 (CST) 
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM) 
id AAQ3003; Wed, 28 Feb 1996 08:54:31 -0800 
Date: Wed, 28 Feb 1996 08:54:31 -0800 (PST) 
From: Johan Forrer <forrerj@ucs.orst.edu> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:916] Re: QST tidbits 
In-Reply-To: <199602280203 .UAA22485@mailhost.onramp.net> 
Message-Id: <Pine.OSF.3.91.960228084251 .27038A-100000@ucs.orst.edu> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi Frank, 


On Tue, 27 Feb 1996 fperkins@onramp.net wrote: 
Hi Johan, 
Here is a couple of cents more: 


Re the DSP-93 and AMTOR, I have shown it receiving AMTOR using you TOR 
program on several of my DSP-93 videos as seen at the DCC and AMSAT 
conferences. The modem side was pretty easy - TOR does the hard part. 
I was just wondering if you had done any experimenting with the DSP-93 
TOR combo. 


VVVVVV VV WV 


Besides just trying it out and getting it to work, I have not done much 
further. One of those things on the "to do list" that I hope to explore 
one of these days. I also need to update the Pactor. 


If anyone does not know about it yet - the source code for the TOR 

modes that I wrote has been available in the "TORLIB.ZIP" file on the 
HFSIG upload area for some time. It is for the sound card DSP board, 
though can be used with any modem with a bit of work. Feel free to use it 
and share your experiences. 


Out of frustration in trying to define SW to do an AX.25 FCS 
calculation, I threw a bit of code together for the Bell 202 modem 
on the DSP-93, so I could push raw packets out the DSP-93 UART 

and get a look at the structure of the FCS. In case anyone is 
interested: 


All bytes in the packet EXCEPT the FCS are sent LSB ‘1st. 


VV VV VV VV WV 


> The FCS is sent high byte first, MSB first. The AX.25 spec nicely 
> gets around defining this by referring to an obscure CCITT spec. 


Thanks for the feedback Frank. I have scratched my head over that one as 
well. I recently have made a hack to Pawel's AX25DRV program, which is a 
TSR that reads the raw bit stream from the serial port. This program very 
nicely unscrambles the raw data and provides the interrupt hook for NOS's 
"attach" command. This way I had a TI320C26 DSK running on HF Packet (of 
course only reading the mail). This agrees with your next comment. 


Based on this quick, rough hack, I don't think there would be any problem 
adding HDLC and KISS to the 300 and 1200 bps modems - if someone has the 
time and interest to pursue it. For the reasons you explained, I don't 
this is practical for 9600 bps. 


73 Frank WB5IPM 


VV VV VV VV VV 


Not to pursue this thread much further here on HFSIG, I just wanted to 
leave this with a last comment. I wonder if the 9600 baud DSP-93 modem 
problem could not be solved using a multirate technique, i.e., a number 
of downsample/upsample filters with the appropiate fractional ratio to 
get you to an exact multiple of 9600. This might consume less clock 
cycles and leave the possibilities for other features. Just a thought. 


--Johan 


From forrerj@ucs.orst.edu Wed Feb 28 10:59:30 1996 
Received: from ucs.orst.edu (forrerj@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.4/8.7.3/1.8) with SMTP id KAAQ0198 for <hfsig@tapr.org>; Wed, 28 Feb 1996 
10:59:28 -0600 (CST) 
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM) 
id AA31331; Wed, 28 Feb 1996 08:59:25 -0800 
Date: Wed, 28 Feb 1996 08:59:24 -0800 (PST) 
From: Johan Forrer <forrerj@ucs.orst.edu> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:917] Sound Blaster 
In-Reply-To: <199602280248 .SAA26541@ravel .n2.net> 
Message-Id: <Pine.OSF.3.91.960228085514..27038B-100000@ucs.orst.edu> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi Brian, 


Nice to hear from you on the list. I think your experiences with the CL 
products at that level basic level is quite interesting. 


You certainly are in ahead of the pack with your work - hope a solution 
to the sampling problem can be found. 


Keep us posted on your activities. 
--Johan 


From cbuttsch@biggulp.callamer.com Wed Feb 28 12:27:06 1996 

Received: from biggulp.callamer.com (cbuttsch@biggulp.callamer.com [199.74.141.2]) 
by tapr.org (8.7.4/8.7.3/1.8) with ESMTP id MAAQ4449 for <hfsig@tapr.org>; Wed, 28 
Feb 1996 12:27:01 -0600 (CST) 

Received: (from cbuttsch@localhost) by biggulp.callamer.com (8.7.4/8.7.3) id 
KAA14748; Wed, 28 Feb 1996 10:26:52 -@800 (PST) 

Date: Wed, 28 Feb 1996 10:26:52 -0800 (PST) 

From: Clifford Buttschardt <cbuttsch@biggulp.callamer.com> 

To: Brian Beezley <k6ésti@n2.net> 

cc: hfsig@tapr.org 

Subject: Re: [HFSIG:917] Sound Blaster 

In-Reply-To: <199602280248 .SAA26541@ravel .n2.net> 

Message-ID: <Pine.OSF.3.91.960228102227 .23115G-100000@biggulp.callamer.com> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi Brian, Johan and the group.. First Brian, I have both of your 
E-messages and especially appreciate the comments to hfsig regarding the 
sound blaster. I am more than willing to wait until a laptop can be 
arranged to do the job. Johans explaination of the difficulties with the 
DSP 93 on 9600 baud as well as AMTOR/PACTOR was even more interesting. 
Thanks to all. Cliff W6HDO 


From cbuttsch@biggulp.callamer.com Wed Feb 28 15:53:17 1996 

Received: from biggulp.callamer.com (cbuttsch@biggulp.callamer.com [199.74.141.2]) 
by tapr.org (8.7.4/8.7.3/1.8) with ESMTP id PAA13487 for <hfsig@tapr.org>; Wed, 28 
Feb 1996 15:53:13 -0600 (CST) 

Received: (from cbuttsch@localhost) by biggulp.callamer.com (8.7.4/8.7.3) id 
NAAQ8901; Wed, 28 Feb 1996 13:52:46 -0800 (PST) 

Date: Wed, 28 Feb 1996 13:52:45 -0800 (PST) 

From: Clifford Buttschardt <cbuttsch@biggulp.callamer.com> 

To: Robert.Glassey@nmp.nokia.com 

cc: hfsig@tapr.org 

Subject: Re: [HFSIG:918] Re: QST tidbits 

In-Reply-To: <H00002920138a6d3@MHS> 

Message-ID: <Pine.OSF.3.91.960228135145 .5274E-100000@biggulp.callamer.com> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Your comments regarding BPSK and demods without processor well noted! 
Thanks....Cliff Buttschardt W6HDO 


From crlbyers@garlic.com Wed Feb 28 19:10:27 1996 
Received: from garlic.com (garlic.com [165.227.35.130]) by tapr.org 
(8.7.4/8.7.3/1.8) with ESMTP id TAA21689 for <hfsig@tapr.org>; Wed, 28 Feb 1996 
19:10:24 -0600 (CST) 
Received: from notnos2 by garlic.com (8.7.4/4.03) 

id RAA62910; Wed, 28 Feb 1996 17:10:21 -0800 


Message-ID: <3134FB62.6E19@garlic.com> 
Date: Wed, 28 Feb 1996 17:03:30 -0800 
From: Carol Byers <crlbyers@garlic.com> 
Organization: noino's 

X-Mailer: Mozilla 2.0Ib6a (Wini6; I) 
MIME-Version: 1.0 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:917] Sound Blaster 
References: <199602280248.SAA26541@ravel.n2.net> 
Content-Type: text/plain; charset=us-ascii 
Content-Transfer-Encoding: 7bit 


Hey Brian, 


When you were real young, did you live on o'Dell street in Edison Park, 
I1.?? 


From fperkins@onramp.net Wed Feb 28 21:59:07 1996 

Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by tapr.org 
(8.7.4/8.7.3/1.8) with ESMTP id VAAQ1027 for <hfsig@tapr.org>; Wed, 28 Feb 1996 
21:59:05 -0600 (CST) 

Received: from 199.184.212.207 (stockyard44.onramp.net [199.184.212.207]) by 
mailhost.onramp.net (8.7.3/8.6.5) with SMTP id UAA26330 for <hfsig@tapr.org>; Wed, 
28 Feb 1996 20:57:43 -0600 (CST) 

Date: Wed, 28 Feb 1996 20:57:43 -0600 (CST) 

Message-Id: <199602290257 .UAA26330@mailhost.onramp.net> 

MIME-Version: 1.0 

Content-Type: text/plain 

Content-Transfer-Encoding: 7bit 

From: fperkins@onramp.net 

Subject: Re: [HFSIG:921] Re: QST tidbits 

To: hfsig@tapr.org 

In-Reply-To: <Pine.OSF.3.91.960228084251.27038A-100000@ucs.orst.edu> 

X-Mailer: SPRY Mail Version: 04.00.06.17 


Hi Johan, 


This (up/down resampling) might be possible. It would be great if the AIO 
sampling rate was capable of fine adjustment (corse adjustment is possible but 
would "shock" the DSP calculations). With fine adjustment, 

you could lock the AIO sampling rate to the locally extacted clock and get good 
results with a much lower sampling rate. 


73 Frank WB5IPM 


From NOAOT@aol.com Wed Feb 28 23:57:14 1996 

Received: from emout09.mail.aol.com (emout09.mx.aol.com [198.81.11.24]) by 
tapr.org (8.7.4/8.7.3/1.8) with SMTP id XAAQ7303 for <hfsig@tapr.org>; Wed, 28 Feb 
1996 23:57:11 -0600 (CST) 

From: NOAOT@aol.com 

Received: by emout09.mail.aol.com (8.6.12/8.6.12) id AAAQ9945; Thu, 29 Feb 1996 
00:57:34 -0500 

Date: Thu, 29 Feb 1996 00:57:34 -0500 


Message-ID: <960229005733_156262947@emout09.mail.aol.com> 
To: forrerj@ucs.orst.edu 

cc: amsat-bb@amsat.org, hfsig@tapr.org 

Subject: Re: Latest news 


In a message dated 96-02-27 14:47:19 EST, forrerj@ucs.orst.edu (Johan Forrer) 
writes: 


>The main problem with 9600 baud is that, besides the modem (which is 
>quite simple), is data and clock recovery and then HDLC decoding. For 
>9600 baud the symbols are very short and ideally one would like to have 
>good edge resolution, say 1/250 of the symbol max jitter. That calls for 
>very heavy duty front end oversampling. That is why the TAPR DSP-93 
>needs an outboard TNC to do this. 


>We have been using the Motorola 56002 EVM for this ($150) and have 
>managed to do it all on the DSP chip, i.e. modem + HDLC and serial 
>communications at 19.2K. There is one fellow that tells me he uses it 
>with WISP. 


Hi Dr. Johan, 


Thanks for the nice note. I had no idea someone already had a 9600 baud modem 
running on the EVM! This makes me wonder what else is already available? 
Sounds like the EVM is more versatile than the DSP-93... Does anyone keep a 
list/library of all the stuff that is currently available for the EVM? 


If 9600 baud and amtor/pactor are already available, I'll order one tomorrow! 
Then I can use it to develop new stuff besides... Neat! 


In order to recommend a pacsat radio to you, I need to know more about your 
requirements. Personally, I am mainly interested in the pacsats for 
world-wide email, so the radio requirements and antenna requirements are be 
much less than for working ssb and sstv on ao-13, for instance. I have made 
minor mods to a Kenwood TM-733a dual bander for pacsat use. These radios are 
much cheaper than "real" satellite radios. If you let me know what you want 
to do on the satellites, I might be able to help you more... 


Thanks Much, 
--Bob, nQaot@amsat.org 


From 72253.2602@compuserve.com Thu Feb 29 10:40:13 1996 
Received: from arl-img-6.compuserve.com (arl-img-6.compuserve.com [198.4.7.6]) by 
tapr.org (8.7.4/8.7.3/1.8) with SMTP id KAAQ4366 for <hfsig@tapr.org>; Thu, 29 Feb 
1996 10:39:59 -0600 (CST) 
Received: by arl-img-6.compuserve.com (8.6.10/5.950515) 
id LAAQ9180; Thu, 29 Feb 1996 11:06:00 -0500 
Date: 29 Feb 96 11:03:57 EST 
From: Peter Schulze <72253.2602@compuserve.com> 
To: HFSIG <hfsig@tapr.org> 
Subject: Re: Sound Card Interface 
Message-ID: <960229160356_72253 .2602_EHJ113-3@CompuServe.COM> 


Hi Brian, 


>Not a bad idea, Peter, except that then I would have to deal with the 
>real-time limitations of both the Windows sound interface and the Creative 
>Labs device driver it calls. Although cascaded, perhaps these interfaces 
>are better suited for low-delay, continuous, real-time I/0. I don't know. 
>At least in DOS, you can obtain direct access to the sound card hardware 
>without asking permission and then do whatever is necessary to get it to 
>work. Apparently due to the demands of game developers, Win95 now 
>incorporates a DirectSound interface that lets a program bypass Windows and 
>do the same thing. 


Directsound won't help you a lot as it is mainly targeted to mix and output 
sounds 
in sync with screen events. There is nothing in there on the wave input side. 


As somebody mentioned before, as long as you are not tight on timing (read RTTY 
for example) 

you can live with the delays, but when you need to keep in pace with an ARQ 
protocol 

it can become difficult. 

I wonder if anybody ever thought about a new ARQ protocol that works ‘one 
behind' ? 

I mean, that you prepare the ‘answer' block while receiving a block and it is 
then sent 

next time you are on TX. Hope you understand what i mean. This would give ample 
time 

to analyze a recieved block of data and prepare the reply. 


I shall set up some kind of timing loop here one day and see what delays are 
involved 

when getting wave input under windows with the win drivers... trigger some kind 
of signal 

on the mic-input under program control and see how long it takes before it 
appears 

in the samples. 


I see a discussion about ways to implement AX25 for the new HF modems. 

To my opinion thats a bad track. To much overhead, lack of forward error 
correction etc.. 

It may seem appealing at the first hand to gain easy access to an existing 
application 

software base, but long time the disadvantages of AX25 will dominate.. 
Same is true for TCP/IP... just to much overhead for low thruput channels. 
Makes no sense to put all effort into faster modems and then eat it up 
with protocols that don't fit... 


73 Peter 
From forrerj@ucs.orst.edu Thu Feb 29 22:25:24 1996 


Received: from PEAK.ORG (root@PEAK.ORG [198.68.23.17]) by tapr.org 
(8.7.4/8.7.3/1.8) with SMTP id WAA26669 for <hfsig@tapr.org>; Thu, 29 Feb 1996 


22:25:19 -Q600 (CST) 

Received: from p03.tO0.monrotel.com (p03.tO.monrotel.com [198.68.25.36]) by 
PEAK.ORG (8.6.12/8.6.7) with SMTP id QAAQ8316 for <hfsig@tapr.org>; Thu, 29 Feb 
1996 16:51:22 -0800 

Message-Id: <199603010051.QAAQ8316@PEAK .ORG> 

X-Sender: forrera@kira.peak.org (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Thu, 29 Feb 1996 16:58:30 -0800 

To: hfsig@tapr.org 

From: forrerj@ucs.orst.edu (Johan Forrer) 

Subject: HF data link layer (was:Sound Card Interface) 


Peter, 


>As somebody mentioned before, as long as you are not tight on timing (read RTTY 
>for example) 

>you can live with the delays, but when you need to keep in pace with an ARQ 
>protocol 

>it can become difficult. 


Yes that is correct. Pactor I for instance has a frame cycle time of 1250 
ms, the data being 960 ms, thus the "dead time" is some 290 ms. The "dead 
time" is taken up by a) propagation time to the receiver, b) the reverse 
channel control command, c) tx/rx changeover delays, d) sending the control 
signal. Subtracting the time for sending the control signal, i.e., 120 ms, 
leaves 170 ms for all the propagation times and changeover times. This 
scheme allows for a 20,000 km maximum distance point-to-point. It is obvious 
that any other delays will probably mess things up. 


>I wonder if anybody ever thought about a new ARQ protocol that works 
>behind' ? 

>I mean, that you prepare the 'answer' block while receiving a block and it is 
>then sent 

>next time you are on TX. Hope you understand what i mean. This would give 
ample 

>time 

>to analyze a recieved block of data and prepare the reply. 


one 


There is an ARQ protocol that works like this, i.e., only way down the line 
does the receiver request certain blocks to be resent. I think this is 
called "Go back N" ARQ. Implementation of these things gets complicated 
rather quickly because one have to assume that the reverse channel is also 
subject to being corrupted. So there are a lot of shuffling going on for 
missing parts. I hope I never have to do one of those :-) 


>I see a discussion about ways to implement AX25 for the new HF modems. 
>To my opinion thats a bad track. To much overhead, lack of forward error 
>correction etc.. 


>It may seem appealing at the first hand to gain easy access to an existing 
>application 
>software base, but long time the disadvantages of AX25 will dominate.. 


I don't think you have to worry much about this Peter. What we have done was 
only a quick and dirty hack to try out some modems. 


You must have been following the discussions over the past few weeks on the 
proposed new data link layer. We were discussing certain parts of the frame, 
i.e., the sync vector and the reverse channel signaling. What goes inbetween 
these are still undecided. Ideally though I would like to see convolutional 
codes with the ability to use punctured codes when conditions are good. 


These are only suggestions, so it's open for discussion. Perhaps you would 
like to share your ideas?? 


>Same is true for TCP/IP... just to much overhead for low thruput channels. 


I think you mean encapsulating TCP/IP in the existing schemes, which I agree 
is not workable. Hopefully there would be a way to minimize the overhead, 
yet retain the ability to utilize networking capabilitie with the scheme 
proposed above. 


Again, we welcome input on this topic. 


--Johan 


From cbuttsch@slonet.org Thu Feb 29 22:29:26 1996 

Received: from biggulp.callamer.com (root@biggulp.callamer.com [199.74.141.2]) by 
tapr.org (8.7.4/8.7.3/1.8) with ESMTP id WAA26928 for <hfsig@tapr.org>; Thu, 29 
Feb 1996 22:29:20 -0Q600 (CST) 

Received: (from cbuttsch@localhost) by biggulp.callamer.com (8.7.4/8.7.3) id 
RAAO4311; Thu, 29 Feb 1996 17:02:50 -0Q800 (PST) 

Date: Thu, 29 Feb 1996 17:02:49 -0Q800 (PST) 

From: Clifford Buttschardt <cbuttsch@slonet.org> 

X-Sender: cbuttsch@biggulp.callamer.com 

To: David Nulton <dnult@atlas.axiom.net> 

cc: Johan Forrer <forrerj@ucs.orst.edu>, hfsig@tapr.org 

Subject: Re: Need Recommendation for DSP Design 

In-Reply-To: <199602291759.LAA27489@atlas.axiom.net> 

Message-ID: <Pine.OSF.3.91.960229165312 .19842C -100000@biggulp.callamer.com> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi David. Thanks for the suggestion on the 320. I did not know that 16 
bit processing was used and therefore switching is needed to use 8 bit 
EPROMS. Good suggestion. I am trying to develop some newer BiPhase 
Frequency Shift decoding protocols and at the same time, keep it simple 
enough to where ordinary people can participate. In general, we have 
been using the computer to maximum ability and making up the difference 
in hardware. So far we have reached the level where a Pentium is 


required and have backed down to where 486/66 units will operate. This 
still seems to exceed the capabilities of the 320. We have gotten this 
far by "stealth"---using clever programming, but I have no clue if the 
existing TMS320C25 programs have tried to increase speed in a like manner. 
Thanks again for your help. Cliff Buttschardt W6HDO Cal Poly, SLO, CA 


